Conception Et Adapation BD Merise2 [PDF]

Zitiervorschau

BTS Services informatiques aux organisations – 2e année Spécialité Solutions logicielles et applications métiers

CONCEPTION ET ADAPTATION D’UNE BASE DE DONNÉES COURS

BTS Services informatiques aux organisations – 2e année

José Gil – Élisabeth Martins Da Silva

CONCEPTION ET ADAPTATION D’UNE BASE DE DONNÉES Retrouvez la liste de nos formations sur www.cned.fr Pour plus d’informations, appelez le 05 49 49 94 94 Du lundi au vendredi, 8 h 30-18 h. Coût d’une communication ordinaire.

*82955TGPA0013*

COURS

www.cned.fr

CONNECTÉ À VOTRE AVENIR

Les cours du CNED sont strictement réservés à l’usage privé de leurs destinataires et ne sont pas destinés à une utilisation collective. Les personnes qui s’en serviraient pour d’autres usages, qui en feraient une reproduction intégrale ou partielle, une traduction sans le consentement du CNED, s’exposeraient à des poursuites judiciaires et aux sanctions pénales prévues par le Code de la propriété intellectuelle. Les reproductions par reprographie de livres et de périodiques protégés contenues dans cet ouvrage sont effectuées par le CNED avec l’autorisation du Centre français d’exploitation du droit de copie (20, rue des Grands Augustins, 75006 Paris). © CNED 2013

Sommaire Conseils généraux 5 Séquence 1 : Le modèle relationnel

7

Séquence 2 : Le modèle conceptuel de données

15

Séquence 3 : Extensions sous Merise/2

71

Séquence 4 : MCD ou Diagramme de classe ?

111

Séquence 5 : La programmation du SGBDR

139

Séquence 6 : Autocorrection

171

8 2955 TG PA 00

Conseils généraux Présentation générale du module Ce module intervient tout au long de la deuxième année, dans le cadre du cours 2955 "Conception et adaptation d'une base de données". Le référentiel lui réserve en moyenne 6 heures de cours/TP par semaine sur 12 semaines, ce qui représente un volume total de 72 heures. Le référentiel est en partie basé sur la répétition, la consolidation des notions et l'apprentissage "en escalier". Ne soyez donc pas surpris si vous retrouvez des notions déjà abordées : c'est l'occasion pour vous soit de les consolider, soit de mieux les comprendre si vous éprouvez des fragilités. Dans des modules précédents, vous avez eu l'occasion d'apprendre à interpréter un schéma conceptuel de données et à le faire évoluer suivant les besoins du cahier des charges. Ce module va plus loin et a pour finalité de vous apprendre à construire de bout en bout un schéma conceptuel de données complet. Vous allez aussi découvrir de nouvelles notions à travers l'insertion de contraintes et les possibilités de les programmer directement dans un SGBDR. Ce module concerne uniquement l'option SLAM. À l'examen, il va intervenir à différents niveaux sur l'ensemble des épreuves informatiques. À l'épreuve écrite, vous devrez entre autres travailler sur un modèle de données, voire en créer un, et lors des épreuves pratiques vous aurez à présenter une application qui exploite une base de données. L'utilisation d'un logiciel de conception est aussi incontournable.

Connaissances nécessaires pour aborder ce module Il est préférable d'avoir réalisé tous les modules prévus pour le premier et second semestre de la première année avant d'aborder celui-ci. Cependant les prérequis incontournables sont : –– le module 2943 "Exploitation des données" ; –– le module 2949 "Exploitation d'un schéma de données".

Page 5

Organisation du module Ce module se présente en trois fascicules. Le fascicule de "cours", le fascicule de "travaux pratiques" et enfin le fascicule de "devoirs". Le fascicule de cours contient toutes les notions fondamentales exigées pour l'examen. Vous devez donc l'étudier en détail et contrôler, par les exercices, que les connaissances sont bien acquises. Le fascicule de travaux pratiques comporte deux TP : –– le premier TP porte sur l’évolution d'une base de données en fonction d'un cahier des charges précis. C'est aussi l'occasion de manipuler WinDesign. Ce TP est à réaliser à l'is-sue de la séquence 4 ; –– le second TP porte sur la prise en compte de contraintes métiers et la conception de programmes dans un environnement de bases de données. Ce TP est l’occasion de mettre en pratique les connaissances acquises en programmation du SGBD. Ce TP est à réaliser à l’issue de la séquence 5. Vous avez 2 devoirs à renvoyer : –– le premier devoir est à réaliser à l'issue de la séquence 4 : il porte sur l'élaboration de schémas conceptuels de données en vue de la création d'une base de données ;

8 2955 TG PA 00

–– le second devoir est à réaliser à l’issue de la séquence 5 : il porte sur la programmation du SGBD. 

Organisation du fascicule Ce fascicule s'articule en 6 séquences : Séquence 1 : Le modèle relationnel Vous allez mieux comprendre les règles de création et de validation d'un schéma conceptuel de données. Séquence 2 : Le modèle conceptuel de données Cette séquence est une reprise des notions abordées dans le module 2949 "Exploitation d'un schéma de données" mais de façon nettement plus formelle et plus approfondie. C'est donc l'occasion de consolider des connaissances tout en allant plus loin. Dans cette séquence et la suivante, vous connaissez déjà certains exercices mais traités de façon différente. Séquence 3 : Extensions sous Merise/2 Vous allez aborder les extensions de Merise/2 qui vous sont pour la plupart inconnues et qui sont fondamentales dans ce cours. Séquence 4 : MCD ou Diagramme de Classes ? Cette séquence montre que le diagramme de classes peut aussi être utilisé pour modéliser les données en vue de la création d'une base de données. Séquence 5 : La programmation du SGBDR Conseils généraux

Page 6

Dans cette dernière séquence vous allez découvrir comment écrire des programmes du côté du serveur de gestion de base de données. Séquence 6 : Autocorrection Vous trouverez ici la correction des exercices de ce fascicule.

Logiciels utilisés Dans ce cours et dans le fascicule de TP qui est associé à ce cours, vous allez manipuler essentiellement un SGBDR et un outil de conception que vous connaissez déjà. La configuration et l'installation de ces logiciels ne seront plus expliquées car elles sont déjà présentées en détail dans des modules précédents.

WinDesign WinDesign est un logiciel de modélisation. Si ce n'est déjà fait, le logiciel doit être récupéré à l'adresse suivante : http://www.win-design.com/fr/NEW_dl_WD.htm Vous récupèrerez la version la plus récente et vous l'installerez en prenant les options par défaut. Ce cours a été fait avec la version 10.04 mais une version plus récente ne doit pas poser de problèmes. Vous avez reçu individuellement par mail le code d'enregistrement pour que vous puissiez utiliser le logiciel dans le cadre de l'enseignement, durant l'année scolaire. Ce code ne devra pas être diffusé.

PostgreSQL SGBDR est gratuit et téléchargeable sur le site officiel (http://www.postgresql.fr/accueil). Ce cours a utilisé la version 9.1 mais vous pouvez a priori récupérer la version la plus récente. Ce SGBDR est l'un des plus connus et appréciés dans le monde gratuit : il est très puissant et multiplateforme. Bon courage !

8 2955 TG PA 00

Séquence 1

Le modèle relationnel Cette première séquence présente le modèle relationnel qui définit les règles pour organiser et optimiser les données. Le modèle conceptuel de données est basé sur les règles du modèle relationnel.

u Prérequis Cette séquence pourrait être abordée sans connaissance préalable, mais il est préférable d'avoir étudié le module 2943 "Exploitation des données" et le module 2949 "Exploitation d'un schéma de données" pour mieux comprendre son intérêt.

u Capacités attendues en fin de séquence Avoir compris les règles du modèle relationnel qui sont fondamentales dans la construction du modèle conceptuel de données.

u Contenu 1. Dépendance fonctionnelle ................................................................................... 8 2. Attribut .................................................................................................................... 9 3. Relation ................................................................................................................... 9 4. Comment obtenir le modèle relationnel ? ....................................................... 12

Synthèse

Page 7

................................................................................ 13

8 2955 TG PA 00

Le modèle relationnel permet d'organiser et de représenter les données de façon indépendante des traitements. Il est basé sur le concept des dépendances fonctionnelles (notion qui va être détaillée juste après). Il obéit à un ensemble de règles bien précises.

1. Dépendance fonctionnelle Avant de présenter une définition formelle, il faut bien comprendre qu'une dépendance fonctionnelle représente un lien entre 2 attributs. Elle permet de mettre en relief le fait qu'un attribut dépend d'un autre. Du coup, en repérant les différentes dépendances fonctionnelles qui existent entre l'ensemble des attributs à modéliser, il est possible de mieux gérer leur organisation. Cette notion est donc fondamentale.

Définition Soient 2 attributs A et B, on dit que B dépend fonctionnellement de A (noté A à B) si, à chaque valeur de A ne correspond qu’une seule valeur de B. n°insee à nom

car il n’y a pas 2 personnes ayant le même n°insee (à chaque n°insee correspond un seul nom) par contre : nom à n°insee

car il peut y avoir des homonymes

Séquence 1 Le modèle relationnel

Page 8

Par habitude, dépendance fonctionnelle est aussi notée DF.

DF élémentaire Soient 2 attributs A et B, la DF (A à B) est élémentaire s’il n’existe pas C contenu dans A tel que (C à B). non élémentaire idCommande, idArticle à nomArticle avec les 2 premières informations, on obtient la dernière mais on n’a pas besoin des 2 informations. L'idArticle suffit pour obtenir le nomArticle : élémentaire idArticle à nomArticle par contre, dans l’exemple suivant, les 2 sont nécessaires : élémentaire

idCommande, idArticle à qteCommandée

Donc une DF élémentaire ne suppose pas forcément un seul attribut à gauche.

DF directe Soient 2 attributs A et B, la DF (A à B) est directe s’il n’existe pas C tel que (A à C) et (C à B). nous possédons, entre autres, les attributs suivants : idClient, nomClient, idCommande

que penser de la DF suivante ? idCommande à nomClient

non directe

la première information donne bien la seconde, mais un intermédiaire paraît logique : idCommande à idClient idClient à nomClient

8 2955 TG PA 00

directes

Exercice 1 Voici les attributs disponibles : idClient, nomClient, adrClient, idArticle, idCommande, dateCommande, qteCommandée

nomArticle,

prixArticle,

Pour les propositions suivantes, précisez s'il y a une DF, si elle est élémentaire, si elle est directe (mettez une croix dans les cases concernées). DF

élém.

directe

nomClient à adrClient idClient à adrClient idCommande, idClient à qteCommandée idCommande, idArticle à prixArticle idCommande, idArticle à qteCommandée idCommande à dateCommande idCommande à nomClient idCommande à nomArticle

2. Attribut Séquence 1

L'attribut est le plus petit élément d'information qui a un sens indépendamment des autres.

Le modèle relationnel

Exemples d'attributs : Page 9

idCommande dateCommande idClient nomClient ...

Un attribut est nommé, il contient une information élémentaire, qui est typée (entier, réel, texte, booléen, date…) et qui peut se voir attribuer une longueur.

3. Relation Une relation est très officiellement un sous-ensemble du produit cartésien d'une liste d'attributs. Avant tout cela signifie qu'une relation peut contenir 1 à plusieurs attributs. Nous verrons par la suite comment regrouper ces attributs en relations. Ensuite, puisque chaque attribut peut avoir plusieurs contenus possibles, il existe un grand nombre de combinaisons possibles (produit cartésien) en utilisant toutes les valeurs des attributs. La relation ne représente pas toutes les possibilités de combinaisons mais juste un sous-ensemble. Imaginons les attributs suivants avec plusieurs valeurs possibles : nomClient : Dupont, Bernard, Durand villeClient : Nice, Marseille

En réunissant ces 2 attributs, on obtient la liste de combinaisons suivante : Dupont – Nice Dupont – Marseille Bernard – Nice

8 2955 TG PA 00

Bernard – Marseille Durand – Nice Durand – Marseille

En revanche, seules les informations en couleur sont vraies et ce sont celles qui seront mémorisées dans la relation. L'exemple a présenté les valeurs que l'on peut retrouver dans une relation. Cependant, l'écriture d'une relation présente dans un premier temps la liste des attributs qui la compose. Une relation possède aussi un nom. Voici quelques exemples de relations : Client (idClient, nomClient, adrClient) Commande (idCommande, dateCommande, idClient) Article (idArticle, nomArticle) LigneCommande (idCommande, idArticle, qteCommandée)

Vous commencez à voir que ces relations regroupent les attributs qui ont un lien entre eux. Peut-être que la notion de dépendance fonctionnelle va bientôt resservir…

Représentation Une relation peut être représentée de 2 façons. Représentation en compréhension Cette représentation permet de voir juste la liste des attributs. Client (idClient, nomClient, ville) Séquence 1

Représentation en extension

Le modèle relationnel

Cette représentation permet de voir aussi le contenu des attributs.

Page 10

idClient

nomClient

ville

45

DUPONT

Nice

62

BERNARD

Marseille

78

DURAND

Marseille

...

...

...

TUPLE (ligne) : une occurrence donc un client

ATTRIBUT (colonne)

Degré et cardinalité Le degré d'une relation représente son nombre d'attributs. Client (idClient, nomClient, ville) Degré = 3

Le degré de cette relation est 3 (3 attributs) La cardinalité d'une relation représente son nombre de tuples. Cardinalité = 20

Si la relation Client contient 20 tuples, donc 20 clients, sa cardinalité est de 20.

Clé primaire La clé d'une relation est l'attribut ou l'ensemble d'attributs qui permet de distinguer entre eux tous les tuples de la relation. Pour la relation : Client (idClient, nomClient, ville)

Les clés candidates sont : idClient idClient, nomClient 8 2955 TG PA 00

idClient, ville idClient, nomClient, ville

En effet, toutes ces combinaisons permettent d'obtenir un client unique. La clé primaire d'une relation est la clé candidate possédant le moins d'attributs possible. Dans l'exemple précédent, la clé primaire est : idClient

En effet, l'idClient est suffisant pour identifier de façon unique un client. La clé primaire est soit soulignée dans une relation (très ancienne notation, mais à connaître) soit précisée sous la relation (notation officielle). Vous devez connaître les 2 notations. Ancienne notation : Client (idClient, nomClient, ville)

Nouvelle notation officielle : Client (idClient, nomClient, ville) idClient : clé primaire

Clé étrangère Une clé étrangère est un attribut d'une relation qui a un rôle de clé primaire unique dans une autre relation. Du coup, la clé étrangère permet de faire le lien entre les relations et ainsi de récupérer facilement des informations d'une relation à une autre. Il existe aussi 2 notations pour la clé étrangère (avec un # dans l'ancienne notation, ou précisé sous la relation dans la notation officielle) : Ancienne notation :

Séquence 1

Client (idClient, nomClient, ville) Commande (idCommande, dateCommande, idClient#)

Le modèle relationnel

Nouvelle notation officielle : Client (idClient, nomClient, ville) idClient : clé primaire Commande (idCommande, dateCommande, idClient) idCommande : clé primaire idClient : clé étrangère en référence à idClient de Client

Page 11

Formes normales Il est temps de reparler de dépendance fonctionnelle. La construction des relations ne doit pas se faire "au hasard", vous vous en doutez. Le but est de trouver l'organisation la plus optimale possible. Pour cela, il suffit de respecter certaines règles. Voici la règle (ou plutôt le groupe de règles) à respecter : Une relation doit posséder une clé primaire et des attributs qui doivent être en DF élémentaire et directe avec la clé primaire. La forme obtenue en suivant ces règles s'appelle la 3e forme normale. On dit que les relations sont en 3NF (l'inversion vient de l'anglais…). S'il y a une 3e forme normale, c'est que peut-être il existe les 2 premières formes. C'est le cas. Alors pour le plaisir, voyons les 3 définitions officielles des formes normales. Première forme normale (1NF) : La relation possède une clé primaire. Commande(idCommande, idArticle, qteCommandée, date, idClient, nomClient)



8 2955 TG PA 00

Il y a bien une clé primaire (mais date n'est pas en DF élémentaire avec la clé car idCommande est suffisant pour donner la date de la commande, et nomClient n'est pas en DF directe avec la clé car il y a un intermédiaire : idClient) Deuxième forme normale (2NF) : La relation est en 1NF et les attributs sont en DF élémentaires avec la clé. Commande (idCommande, date, idClient, nomClient)

Il y a bien une clé primaire et les DF sont élémentaires (mais nomClient n'est pas en DF directe avec la clé car il y a un intermédiaire : idClient) Troisième forme normale (3NF) : La relation est en 2NF et les attributs sont en DF directes avec la clé. Commande (idCommande, date, idClient#)

Il y a bien une clé primaire et les DF sont élémentaires et directes. Le but est maintenant de faire en sorte que toutes les relations qui seront construites soient en 3NF.

Exercice 2 Écrire les relations en 3NF qui vous paraissent logiques à partir de la liste d'attributs suivante :

Séquence 1

idEtudiant, nomEtudiant, idClasse, idMatière, nomClasse, nomMatière, coefMatière, annéeInscription.

Le modèle relationnel

Vous connaissez aussi les règles de gestion suivantes : –– chaque matière peut avoir un coefficient différent suivant les classes ; –– d'une année sur l'autre, un étudiant peut s'inscrire dans des classes différentes, éventuellement dans la même classe mais jamais dans plusieurs classes à la fois : l'année d'inscription est mémorisée.

Page 12

Avez-vous souffert pour faire cet exercice ? Alors imaginez si vous aviez à organiser une cinquantaine d'attributs…

4. Comment obtenir le modèle relationnel ? Lorsqu'un ensemble de données est à traiter, le but est donc d'organiser ces données en relations normalisées (en 3NF). Ces relations pourront alors permettre de créer par exemple une base de données relationnelle, exploitée par un programme. Vous avez compris que, suivant la complexité du sujet, trouver directement les relations risque de rapidement tourner au casse-tête. Il est donc préférable de passer par la construction d'un schéma suivant un modèle précis. L'aspect visuel du schéma permettra de simplifier la construction des relations correspondantes. Vous allez donc apprendre, dans la séquence suivante, à élaborer des schémas basés sur le modèle conceptuel des données de la méthode Merise. Ce modèle est aussi appelé Modèle Entités Associations. Si vous avez étudié les modules précédents, vous savez déjà pourquoi.

8 2955 TG PA 00

Synthèse

Dépendance Fonctionnelle : Soient 2 attributs A et B, on dit que B dépend fonctionnellement de A (A à B) si, à chaque valeur de A ne correspond qu’une seule valeur de B. DF élémentaire : Soient 2 attributs A et B, la DF (A à B) est élémentaire s’il n’existe pas C contenu dans A tel que (C à B). DF directe : Soient 2 attributs A et B, la DF (A à B) est directe s’il n’existe pas C tel que (A à C) et (C à B). Attribut : L'attribut est le plus petit élément d'information qui a un sens indépendamment des autres. Relation : Une relation est un sous-ensemble du produit cartésien d'une liste d'attributs. Représentation en compréhension d'une relation : nomRelation (liste des attributs)

Séquence 1

Représentation en extension d'une relation : cette représentation est sous forme de tableau (avec la liste des valeurs).

Le modèle relationnel

Clé d'une relation :

Page 13

La clé d'une relation est l'attribut ou l'ensemble d'attributs qui permet de distinguer entre eux tous les tuples de la relation. Clé primaire d'une relation : La clé primaire d'une relation est la clé candidate possédant le moins d'attributs possible. Notation : soulignée (ancienne notation) ou en le mentionnant explicitement après la relation (notation officielle). Clé étrangère : Une clé étrangère est un attribut d'une relation qui a un rôle de clé primaire unique dans une autre relation. Notation : avec # (ancienne notation) ou en le mentionnant explicitement après la relation (notation officielle). Exemple : Ancienne notation : CLIENT (idClient, nom, adresse, tel) FACTURE (idFacture, dateFacture, total, idClient#)

 

8 2955 TG PA 00

Nouvelle notation officielle : CLIENT (idClient, nom, adresse, tel) idClient : clé primaire FACTURE (idFacture, dateFacture, total, idClient) idFacture : clé primaire idClient : clé étrangère en référence à idClient de CLIENT

3e forme normale : Une relation doit posséder une clé primaire et des attributs qui doivent être en DF élémentaire et directe avec la clé primaire.

Séquence 1 Le modèle relationnel

Page 14

8 2955 TG PA 00

Séquence 2

Le modèle conceptuel de données Cette séquence reprend toutes les notions fondamentales d’un modèle conceptuel de données, mais cette fois avec le but de savoir construire un schéma de bout en bout. Vous retrouverez toutes les notions déjà étudiées dans le module 2949 "Exploitation d’un schéma de données", à travers une présentation plus formelle et plus complète. Attention, même si vous pensez maîtriser les notions abordées, ne faites pas l’impasse sur cette séquence qui va vous apporter les connaissances nécessaires pour modéliser correctement les données.

u Prérequis Avoir acquis les connaissances de la séquence 1 pour mieux comprendre le principe.

u Capacités attendues en fin de séquence Savoir construire intégralement un schéma conceptuel de données d’une certaine complexité.

u Contenu

Page 15

1. Introduction .......................................................................................................... 16 2. Outils du MCD ...................................................................................................... 16 3. Noms des entités et associations ...................................................................... 18 4. DF entre entités .................................................................................................... 19 5. Cardinalités ........................................................................................................... 19 6. Héritage ................................................................................................................. 19 7. Intégrité fonctionnelle ........................................................................................ 24 8. Lien identifiant ..................................................................................................... 24 9. Agrégation ............................................................................................................ 29 10. Petit mémento du MCD....................................................................................... 31 11. Exercices récapitulatifs de premier niveau ...................................................... 52 12. Exercices récapitulatifs de second niveau ........................................................ 60

Synthèse

8 2955 TG PA 00

................................................................................ 70

8 2955 TP PA 00

1. Introduction Qu’est-ce que le MCD ? Le MCD (Modèle Conceptuel de Données) est un des modèles de la méthode Merise, qui fixe un ensemble de règles pour organiser les données de façon visuelle. Le MCD permet de schématiser les dépendances fonctionnelles. Il respecte les règles du modèle relationnel en ajoutant des règles de représentation graphique.

Qu’est-ce que le SCD ? En suivant les règles de ce modèle, vous allez apprendre à construire des SCD (Schémas Conceptuels de Données) qui répondent aux attentes de contextes précis. Attention, par abus de langage, on utilise souvent le terme MCD pour parler de SCD. C’est-à-dire que vous verrez parfois "dessinez le MCD correspondant au domaine présenté" alors que ce n’est pas le MCD que vous devez dessiner mais le SCD : ce n’est pas vous qui avez inventé le Modèle mais vous êtes un simple utilisateur qui dessine des Schémas basés sur le Modèle ! Cependant cette erreur est courante : ce n’est pas très grave et il faudra vous y habituer. Mais il est important que vous ayez bien compris la différence.

Intérêt du MCD Séquence 2 Le modèle conceptuel de données

Page 16

Le MCD permet de réaliser des schémas qui sont beaucoup plus faciles à construire que l’écriture directe de relations. Ces schémas sont aussi beaucoup plus faciles à lire. Une fois le SCD construit, la traduction en relations est directe.

Vocabulaire du MCD Le vocabulaire est normalement le même que pour le modèle relationnel, avec bien sûr des termes spécifiques au MCD qui vont venir s’ajouter. Apprenez à utiliser aussi le terme identifiant pour parler de clé primaire. Quelle est la nuance ? Normalement aucune : le terme "clé primaire" est la traduction directe du terme anglais "primary key" et le terme "identifiant" est purement français. Certains ont cependant inséré une nuance entre les 2 termes et les positionnent à des niveaux différents : "identifiant" au niveau conceptuel et "clé primaire" au niveau de la base de données. Tout ceci est assez secondaire : il faut juste connaître les 2 termes.

2. Outils du MCD Le MCD n’utilise en fait que 2 outils graphiques : les entités et les associations. Tous les autres éléments du MCD sont des dérivés de ces 2 éléments.

Entité Elle est la représentation graphique d’une relation en 3NF dont la clé primaire n’est composée que d’un seul attribut élémentaire. représentation : exemple :

! NOM ENTITE



8 2955 TG PA 00

attribut1 … attributN

ARTICLE idArticle nomArticle prix



Une entité possède un nom placé dans sa partie haute. Ce nom sera celui de la relation qui en découle. Une entité possède des attributs placés dans sa partie basse au rythme d’un attribut par ligne. Dans une entité, l’identifiant est unique : il est souligné et placé en tête de la liste des attributs. Une entité contient obligatoirement un identifiant suivi de 0 à plusieurs attributs simples. On dit qu’une entité est "vide" quand elle ne possède que l’identifiant. Les éventuelles clés étrangères ne sont pas écrites directement dans l’entité. Nous verrons plus loin comment elles sont symbolisées (pour visualiser le lien qu’elles représentent avec d’autres entités).

Association Elle est la représentation graphique d’une relation en 3NF dont la clé primaire est composée d’au moins 2 attributs élémentaires. représentation : NOM ENTITE …

NOM ASSOCIATION attribut1 … attributN

NOM ENTITE … Séquence 2

exemple : COMMANDE idCommande date

LIGNE_COMMANDE qteCommandée

Le modèle conceptuel de données

ARTICLE idArticle nomArticle prix

Page 17

Une association possède un nom placé dans sa partie haute. Ce nom sera celui de la relation qui en découle. Une association possède éventuellement des attributs placés dans sa partie basse au rythme d’un attribut par ligne. Dans une association, l’identifiant (composé forcément de plusieurs attributs) n’est pas explicitement marqué : les liens directs qui entourent l’association permettent d’aller récupérer les identifiants des entités concernées. L’ensemble de ces identifiants représente l’identifiant de l’association. Il y en a au moins 2. De la remarque précédente, il découle qu’une association possède au moins 2 liens directs qui l’entourent. Une association contient 0 à plusieurs attributs simples. Une association "vide" est une association qui ne contient aucun attribut : on l’appelle aussi CIM (Contrainte d’intégrité multivaluée). Les éventuelles clés étrangères ne sont pas écrites directement dans l’association. Nous verrons plus loin comment elles sont symbolisées (pour visualiser le lien qu’elles représentent avec d’autres entités, mais qui ne sera pas symbolisé par un lien direct).

8 2955 TG PA 00

3. Noms des entités et associations Noms des entités Une entité est classiquement la représentation du réel : personne, lieu, chose… Du coup le nom d’une entité paraît naturel : il suffit de donner le nom qui correspond à l’objet décrit ("objet" dans le sens : représentation du réel). Exemples : facture, client, article…

Noms des associations À ce niveau là c’est un peu plus complexe et il existe plusieurs approches. L’approche la plus courante depuis quelques années et que vous trouverez dans la plupart des sujets, c’est l’utilisation d’un verbe : le verbe symbolise le lien entre 2 entités. Voici un exemple : COMMANDE

CONTIENT

idCommande date

qteCommandée

ARTICLE idArticle nomArticle prix

En nommant l’association "CONTIENT", on constitue une phrase entre les 2 entités : "une commande CONTIENT des articles" Séquence 2 Le modèle conceptuel de données

Page 18

Là, vous pouvez vous poser la question : que se passe-t-il si la lecture se fait dans l’autre sens ? On peut imaginer qu’il suffit de prendre la forme passive : "un article EST CONTENU dans des commandes" Cependant, il arrive que la forme passive ne marche pas. En fait, au début de la création de la méthode, 2 verbes (appelés "rôles") devaient être placés : un par branche. COMMANDE idCommande date

contient

LIGNE_COMMANDE qteCommandée

ARTICLE est contenu

idArticle nomArticle prix

Cette écriture a été rapidement abandonnée et remplacée par un seul verbe comme nom d’association. Sous Win’Design, il est toujours possible d’ajouter ces rôles. Personnellement, cette solution me gène car n’oublions pas que l’association va ensuite se traduire en une relation dans le modèle relationnel, puis une table dans une base de données. Et là, on peut se poser la question du côté "parlant" du nom de la table correspondante. Que pensez-vous d’une table nommée "CONTIENT" par rapport à une table nommée "LIGNE_COMMANDE" ? Ceci dit, ayez l’esprit large et acceptez toutes les approches. L’important est que vous soyez capable de vous adapter à n’importe quelle variante dans les formalismes utilisés. Cependant, quand vous aurez la possibilité de choisir une solution plutôt qu’une autre, faites le choix qui vous convient le mieux, et de préférence suivez toujours la même méthode pour traiter l’ensemble d’un sujet.

8 2955 TG PA 00

4. DF entre entités Vous avez vu dans le modèle relationnel qu’une clé étrangère est un attribut d’une relation, qui a le rôle de clé primaire dans une autre relation. Deux relations sont alors liées par une dépendance fonctionnelle entre les 2 identifiants. Puisqu’il y a un lien, ça donne envie de le symboliser par une association dans le MCD. Partons d’un exemple : une commande ne correspond qu’à un seul client. COMMANDE

CLIENT

CORRESPOND

idClient nomClient adresse

idCommande date

Cette fois, que vous mettiez un verbe ou un nom parlant, cela ne change pas grandchose : dans le cas d’une dépendance fonctionnelle entre 2 entités, l’association ne sera pas traduite en relation mais en clé étrangère dans la relation Commande. Du coup, pour que la représentation de la dépendance fonctionnelle entre les 2 entités soit plus visuelle, une autre représentation est admise (et me semble être nettement la meilleure) : COMMANDE idCommande date

CLIENT idClient nomClient adresse

Séquence 2

Cette représentation évite de donner un nom à l’association (puisque de toute façon ce nom ne sert à rien) et montre visuellement le lien et le sens du lien (cependant, la flèche n’est pas obligatoire : soit elle représente pour vous une aide et dans ce cas il faut la mettre, soit vous avez du mal avec sa position et dans ce cas je vous conseille de l’oublier). Win’Design permet cette représentation en précisant qu’il y a une dépendance fonctionnelle entre les entités (le rond et la flèche apparaissent).

Le modèle conceptuel de données

Page 19

Encore une fois, le but est de savoir lire et manipuler les 2 représentations, cependant je ne saurais trop vous conseiller d’utiliser la seconde notation qui vous aidera à mieux visualiser les dépendances fonctionnelles entre entités. Pour ajouter des couches dans les nuances que vous pouvez trouver dans les schémas, il existe 2 variantes dans la seconde notation : certains ajoutent "DF" dans le petit cercle (pour une raison évidente : c’est une Dépendance Fonctionnelle), d’autres ajoutent "CIF" dans le petit cercle : CIF signifie Contrainte d’Intégrité Fonctionnelle. Cela représente un lien très fort entre les 2 entités puisque l’on parle carrément de "contrainte d’intégrité". En quelque sorte, il y a une perte "d’intégrité" si la première entité ne donne pas la seconde. La nuance entre DF et CIF est assez légère, cependant on y reviendra de façon plus précise juste après, en abordant la notion de cardinalités.

5. Cardinalités Les cardinalités permettent d’exprimer le nombre minimum et maximum d’occurrences d’une entité par rapport à une autre (liées par une association).

8 2955 TG PA 00

Une commande contient au moins un article, mais peut en contenir plusieurs.

COMMANDE

Un article peut se retrouver dans 0 à plusieurs commandes.

1,n

idCommande date

0,n

qteCommandée

1,1 CLIENT

1,n

ARTICLE

LIGNE_COMMANDE

idArticle nomArticle prix

Un commande ne concerne qu'un client (minimum et maximum.)

idClient nomClient adresse

Si l'enregistrement d'un client se fait au moment où il passe sa première commande, alors un client a passé au minimum une commande, cependant il peut ensuite en avoir passé plusieurs. Séquence 2 Le modèle conceptuel de données

Comment se lit une cardinalité ? L’exemple précédent explique bien la signification des différentes cardinalités. De façon plus formelle, voici comment se lit une cardinalité :

!

Page 20

ENTITE1 …

n,m

ASSOCIATION …

ENTITE2 …

"à une occurrence de l’entité1 correspond minimum n, maximum m occurrences de l’entité2" Donc la lecture part de l’entité qui se trouve du côté de la cardinalité.

Quelles sont les cardinalités possibles ? minimum : 0 ou 1 ou plus rarement une autre valeur précise, mais jamais n. maximum : 1 ou n ou plus rarement une autre valeur précise, mais jamais 0.

Exercice 1 Voici un ensemble de relations : dessinez le SCD correspondant. CORPS_CELESTE (idCorps, nom, distance, idSysteme#) SYSTEME (idSysteme, nom) MATIERE (idMatiere, nom) COMPOSITION_CORPS (idCorps#, idMatiere#, quantité)

8 2955 TG PA 00

6. Héritage Il arrive que certaines entités comportent des attributs qui ne seront remplis que sous certaines conditions. En fait, l’entité comporte des "sous-types" qui ont chacun leurs propres caractéristiques. Voyons un exemple pour que ce soit plus clair : Il faut gérer le personnel qui travaille dans un établissement scolaire. Pour l’ensemble du personnel, il faut mémoriser nom, prénom, adresse, téléphone, email. Pour les enseignants, il faut mémoriser le nombre d’heures d’enseignement par semaine et les matières enseignées. Pour les administratifs, il faut mémoriser le service de rattachement et la date d’affectation à ce service. On pourrait imaginer le schéma suivant : 0 minimum car un administratif n'a pas de matière.

PERSONNEL idPersonnel nom prenom adresse tel email nbHeures dateAffectation

0,n

MATIERE_PROF

0,n

MATIERE idMatiere nom

0 minimum car un professeur n'a pas de service : cela donnera une clé étrangère qui sera parfois vide.

0,1

nbHeures et dateAffectation ne seront pas toujours remplis.

0,n

Séquence 2 Le modèle conceptuel de données

SERVICE idService nom

Page 21

Pour éviter ces attributs et clés étrangères parfois vides, on pourrait imaginer une autre solution qui sépare totalement les administratifs des enseignants :

! ADMINISTRATIF

PROFESSEUR idProfesseur nom prenom adresse tel email nbHeures

idAdministratif nom prenom adresse tel email dateAffectation 1,1 0,n

SERVICE idService nom

1,n

MATIERE_PROF

0,n

MATIERE idMatiere nom

Il n'y a plus d'attributs qui peuvent rester vides, mais certains attributs sont identiques. De Depplus, lus, si on a envie de faire faireddes es recherches sur tout le personnel, il faut passer par les 22eentités. ntités.

Finalement, les 2 solutions proposées ne sont pas satisfaisantes. Le but serait de pouvoir gérer le personnel dans son intégralité, mais éviter les attributs qui peuvent rester vides.

8 2955 TG PA 00

La solution : garder l’entité PERSONNEL qui contiendra tout ce qui est commun à tout le personnel, et créer 2 sous-types spécifiques à chaque type de personnel. Voici la représentation graphique : PERSONNEL idPersonnel nom prenom adresse tel email

ADMINISTRATIF

PROFESSEUR

dateAffectation

nbHeures

1,1

1,n

MATIERE_PROF

0,n

MATIERE idMatiere nom

SERVICE 0,n

Séquence 2

Ces flèches, sans cardinalité, symbolisent l'héritage : ADMINISTRATIF et PROFESSEUR sont des entités qui héritent de PERSONNEL .

idService nom

Voyons ce que cela donne au niveau relationnel :

Le modèle conceptuel de données

PERSONNEL (idPersonnel, nom, prenom, adresse, tel, email) ADMINISTRATIF (idPersonnel#, dateAffectation, idService#) PROFESSEUR (idPersonnel#, nbHeures) SERVICE (idService, nom) MATIERE (idMatiere, nom) MATIERE_PROF (idPersonnel#, idMatiere#)

Page 22

Remarquez que dans ADMINISTRATIF et dans PROFESSEUR, la clé primaire est identique à celle de PERSONNEL excepté qu’elle est aussi étrangère. En effet, un ADMINISTRATIF est aussi un PERSONNEL et va donc récupérer certaines de ses informations directement dans PERSONNEL. Donc, si Alain DUPOND est un administratif et que son id vaut 4, on retrouvera cet id 4 aussi bien dans PERSONNEL que dans ADMINISTRATIF : les informations concernant Alain DUPOND seront récupérées dans PERSONNEL avec l’id 4, et les informations concernant DUPOND mais spécifiques au fait qu’il est personnel administratif, seront récupérées dans ADMINISTRATIF avec aussi l’id 4. L’ancienne notation des relations ne fait pas assez bien ressortir le sens des liens. En effet, la clé primaire et étrangère idPersonnel dans MATIERE_PROF ne met pas en évidence le fait que le lien se fait uniquement avec l’entité PROFESSEUR et non avec l’entité PERSONNEL. Voici les mêmes relations avec la nouvelle notation officielle. Vous allez comprendre la différence. PERSONNEL (idPersonnel, nom, prenom, adresse, tel, email) idPersonnel : clé primaire ADMINISTRATIF (idPersonnel, dateAffectation, idService) idPersonnel : clé primaire idPersonnel : clé étrangère en réf. à idPersonnel de PERSONNEL idService : clé étrangère en réf. à idService de SERVICE

8 2955 TG PA 00

PROFESSEUR (idPersonnel, nbHeures) idPersonnel : clé primaire idPersonnel : clé étrangère en réf. à idPersonnel de PERSONNEL SERVICE (idService, nom) idService : clé primaire On voit bien que l'idPersonMATIERE (idMatiere, nom) nel est issu de PROFESSEUR. idMatiere : clé primaire MATIERE_PROF (idPersonnel, idMatiere) idPersonnel, idMatiere : clé primaire idPersonnel: clé étrangère en réf. à idPersonnel de PROFESSEUR idMatiere : clé étrangère en réf. à idMatiere de MATIERE

Quand faut-il utiliser l’héritage ? Logiquement, comme vous l’avez vu, l’héritage semble être nécessaire lorsque des soustypes apparaissent, donc quand des attributs sont génériques (communs à tous les types) et d’autres sont spécifiques à chaque type. Dans la réalité, l’héritage a tout de même un inconvénient : il génère par la suite des tables supplémentaires qui peuvent alourdir la base de données. Du coup, il faut faire des choix stratégiques au moment du passage à la base de données. Attention, ces choix ne se font pas au niveau conceptuel, mais uniquement au moment du passage au niveau relationnel. Pour faire ces choix, soit le modèle présenté est gardé en l’état, soit d’autres solutions sont prises, suivant la situation.

Migration vers l’entité mère Si les entités filles contiennent peu d’informations et ne possèdent aucun lien (associations reliées à elles), alors il est préférable de les supprimer et de migrer leurs attributs vers l’entité mère. Certains attributs resteront parfois vides mais il n’y aura qu’une table à gérer.

Migration vers les entités filles Si au contraire l’entité mère possède peu d’attributs et aucun lien (associations reliées à elle) et si les entités filles ont une activité plus importante (des attributs spécifiques et/ou des liens), alors il est préférable de migrer les attributs de l’entité mère vers les entités filles. Attention, cette solution ne peut être choisie que dans le cas où il n’est pas nécessaire de réaliser de traitements qui regroupent les entités filles.

Séquence 2 Le modèle conceptuel de données

Page 23

Un peu de vocabulaire Pour finir cette partie sur l’héritage, voyons un peu de vocabulaire. Le but n’est pas de l’apprendre par cœur mais de s’y habituer. C’est une première présentation d’un vocabulaire que de toute façon vous allez souvent rencontrer dans les sujets. PERSONNEL

Entité mère Sur-type Entité générique

idPersonnel nom prenom adresse tel email

ADMINISTRATIF dateAffectation

Héritage Dérivation Hiérarchie Sous-typage

PROFESSEUR nbHeures

Entité fille Sous-type Entité spécifique

8 2955 TG PA 00

Exercice 2 Voici un ensemble de relations : dessinez le SCD correspondant. MESSAGE (idMessage, titre, contenu, date, idExpediteur) idMessage : clé primaire idExpediteur : clé étrangère en réf. à idPersonne de PERSONNE MESSAGE_UNIQUE (idMessage, date_reponse, idDestinataire) idMessage : clé primaire idMessage : clé étrangère en réf. à idMessage de MESSAGE idDestinataire : clé étrangère en réf. à idPersonne de PERSONNE DIFFUSION (idMessage) idMessage : clé primaire idMessage : clé étrangère en réf. à idMessage de MESSAGE PERSONNE (idPersonne, nom) idPersonne : clé primaire DESTINATAIRE (idDiffusion, idDestinataire, date_reponse) idDiffusion, idDestinataire : clé primaire idDiffusion : clé étrangère en réf. à idMessage de DIFFUSION idDestinataire : clé étrangère en réf. à idPersonne de PERSONNE

7. Intégrité fonctionnelle Séquence 2 Le modèle conceptuel de données

Une intégrité fonctionnelle traduit une dépendance forte entre des objets. Les SGBDR gèrent généralement les intégrités fonctionnelles automatiquement dès qu’il y a des clés étrangères qui sont définies. Reprenons l’exemple suivant : Un article ne peut pas être supprimé s'il est rattaché à des commandes .

Page 24

COMMANDE idCommande date

1,n

LIGNE_COMMANDE qteCommandée

ARTICLE 0,n

idArticle nomArticle prix

1,1

1,n Une commande ne peut pas être créée si elle n'est pas rattachée à un client.

CLIENT idClient nomClient adresse

Il est possible de demander au SGBDR, lors de la suppression d'une commande, que tous les tuples correspondants dans LIGNE_COMMANDE soient automatiquement supprimés .

8. Lien identifiant Vous allez étudier une notion qui n’existe normalement que depuis Merise/2 (étudié dans la séquence suivante) mais qui apporte une simplification intéressante au niveau de la construction des schémas. Voilà pourquoi cette notion est présentée dès maintenant.

8 2955 TG PA 00

Il arrive que des entités temporelles ou de type "numéro" soient nécessaires pour gérer correctement certaines situations. Voyons tout cela à travers 2 exemples.

1er cas : le lien identifiant pour supprimer les entités numéros

 es hôtels possèdent des chambres. Un numéro de chambre peut se retrouver dans plusieurs L hôtels. Pour chaque chambre, il est nécessaire de connaître le type (simple ou double). La première solution serait de créer une entité CHAMBRE dont l’id ne correspond pas au numéro réel de la chambre (car l’id doit être unique et un numéro de chambre ne l’est pas, d’un hôtel à un autre) :

! CHAMBRE idChambre numChambre type

HOTEL

1,n

1,1

idHotel nom adresse

Au niveau des tables, cela donnerait ceci : HOTEL idHotel

nom

adresse

1

Beausoleil

Marseille

2

Le Rivage

Nice

…

…

…

Séquence 2 Le modèle conceptuel de données

CHAMBRE idChambre

numChambre

type

Page 25

idHotel

1

1

Simple

1

2

2

Double

1

3

3

Double

1

4

4

Simple

1

5

1

Simple

2

6

2

Simple

2

7

3

Double

2

8

4

Simple

2

9

5

Double

2

10

6

Double

2

…

…

…

…

La chambre d’id 6 est la chambre qui porte le numéro 2 de l’hôtel "Le Rivage".

Pourquoi l’id ne correspond pas au numéro réel de la chambre ? Vous voyez bien ici que la chambre de numéro 2 existe dans l’hôtel "Le Rivage" mais aussi dans l’hôtel "Beausoleil". Un identifiant devant être unique, on est obligé de gérer un id qui soit différent du numéro réel de la chambre. Donc idChambre sera un numéro interne automatiquement créé et incrémenté, alors que numChambre sera une information réelle de la chambre (son numéro dans l’hôtel) au même titre que le type de la chambre.

8 2955 TG PA 00

Cette solution marche mais a pour inconvénient d’utiliser un id supplémentaire alors qu’il serait tout à fait possible de s’en passer. Comment ? La seconde solution consiste à utiliser le numéro réel de chambre associé à l’identifiant de l’hôtel pour repérer une chambre précise. Cela pousse à créer une entité "vide" (ne contenant qu’un identifiant) juste pour obtenir un numéro. NUMCHAMBRE

1,n

numChambre

CHAMBRE type

HOTEL 0,n

idHotel nom adresse

L’entité NUMCHAMBRE n’a de raison d’être que pour générer un numéro qui sert à la construction de l’association CHAMBRE. Au niveau relationnel l’entité NUMCHAMBRE disparaît et il ne reste plus que : HOTEL (idHotel, nom, adresse) idHotel : clé primaire CHAMBRE (idHotel, numChambre, type) idHotel, numChambre : clé primaire idHotel : clé étrangère en réf. à idHotel de HOTEL

Cette solution est meilleure que la précédente car le repérage d’une chambre est plus concret : il se fait en fonction de l’hôtel et du numéro réel de la chambre. Séquence 2

Au niveau des tables, cela donnerait ceci : HOTEL

Le modèle conceptuel de données

Page 26

idHotel

nom

adresse

1

Beausoleil

Marseille

2

Le Rivage

Nice

…

…

… CHAMBRE

idHotel

numChambre

type

1

1

Simple

1

2

Double

1

3

Double

1

4

Simple

2

1

Simple

2

2

Simple

2

3

Double

2

4

Simple

2

5

Double

2

6

Double

…

…

…

La chambre portant le numéro 2 de l'hôtel "Le Rivage" est une chambre "simple".

Cette fois, la chambre est repérée (identifiée) par la combinaison de 2 informations : l’idHotel + le numChambre qui est le numéro réel de la chambre dans l’hôtel. On n’a plus besoin d’ajouter un id.

8 2955 TG PA 00

Cette solution permet d’avoir une colonne en moins et en plus d’avoir un identifiant "parlant" (représentant le réel). Mais peut-être que faire de CHAMBRE une association vous gène un peu et la présence de cette entité NUMCHAMBRE qui disparaît ensuite vous gène aussi. Cette représentation un peu "lourde" a aussi gêné les concepteurs de la méthode qui du coup ont mis en place une représentation plus légère et plus visuelle : idChambre a disparu. numChambre (le numéro réel de la chambre) est en identifiant.

CHAMBRE numChambre type

(1,1)

1,n

HOTEL idHotel nom adresse

Les parenthèses autour du 1,1 signale que la clé étrangère sera aussi une clé primaire (donc fera partie de l'identifiant de CHAMBRE) . Qu’est ce que cela change au niveau relationnel par rapport à la représentation précédente ? Rien. Cette représentation n’est là que pour alléger l’aspect visuel du SCD. Au niveau relationnel, on retrouve les 2 relations avec, pour CHAMBRE, 2 attributs en clé primaire. Cette représentation, qui existe uniquement depuis la version 2 de Merise (appelée Merise/2 ou extensions Merise) permet tout simplement d’éliminer toutes les entités de type numéro qui existaient dans l’ancienne version.

Vocabulaire

Séquence 2

Cette notion s’appelle le lien identifiant. Voyons le vocabulaire plus en détail : Entité faible Entité dépendante

CHAMBRE numChambre type

(1,1)

1,n

Le modèle conceptuel de données

HOTEL

Page 27

idHotel nom adresse

CHAMBRE est une "entité faible" (ou "dépendante") car elle n’a pas de vie toute seule : elle dépend directement de l’entité HOTEL puisque son identifiant est, entre autres, constitué de l’identifiant de l’entité HOTEL. numChambre est un "identifiant relatif" car il n’est pas seul à identifier CHAMBRE. Le lien qui relie CHAMBRE à HOTEL est un "lien identifiant" car il permet de compléter l’identification de CHAMBRE. Comme il y a une contrainte forte entre CHAMBRE et HOTEL, on l’appelle aussi "contrainte d’identification".

Autres notations La représentation sous forme de CIF est conseillée car plus visuelle, mais pas du tout obligatoire. Si vous avez choisi de représenter les CIF sous forme d’associations normales, vous pouvez le faire aussi pour les liens identifiants. La représentation sous forme de (1,1) donc avec les parenthèses, n’est pas unique. Il existe 2 autres représentations qu’il faut aussi connaître :

8 2955 TG PA 00

Cette représentation est relativement proche de la précédente.

CHAMBRE numChambre type

Cette représentation est censée être plus "claire" car la seconde clé apparaît directement dans l'entité. Elle est cependant plus "lourde".

CHAMBRE numChambre #idHotel# type

1,1(R)

1,n

1,1

1,n

HOTEL idHotel nom adresse HOTEL idHotel nom adresse

Encore une fois, à vous de prendre la notation que vous préférez. Mais vous devez savoir toutes les lire.

2e cas : le lien identifiant pour supprimer les entités temporelles De la même façon que le lien identifiant permet de supprimer les entités numéros, les entités temporelles peuvent aussi, dans la plupart des cas, être éliminées. Les locations de films doivent être mémorisées. Une location concerne un film à une date précise : il faut aussi enregistrer la date de retour. Séquence 2 Le modèle conceptuel de données

Un film + une date de location permet de déterminer précisément une location : location doit donc naturellement être gérée sous forme d’association entre FILM et DATE. FILM idFilm titre

Page 28

LOCATION

0,n

0,n

dateRetour

DATE dateLocation

Cependant, l’entité DATE n’est là que pour la création de l’association LOCATION et disparaît au niveau du modèle relationnel (car il n’y a aucune raison de garder une relation DATE qui mémoriserait toutes les dates du calendrier !). FILM (idFilm, titre) idFilm : clé primaire LOCATION (idFilm, dateLocation, dateRetour) idFilm, dateLocation : clé primaire idFilm : clé étrangère en réf. à idFilm de FILM

Ici encore, le lien identifiant va permettre de simplifier la représentation sans rien changer au sens : les relations qui en découleront seront les mêmes que les relations précisées juste au-dessus. FILM

1,n

idFilm titre

(1,1)

LOCATION dateLocation dateRetour

Liens identifiants en cascade Vous aurez parfois à gérer des liens identifiants vers des entités qui possèdent déjà un lien identifiant. C’est tout à fait possible.

8 2955 TG PA 00

PLANETE idPlanete nom

(1,1)

1,n

SYSTEME idSysteme nom

(1,1)

1,n

GALAXIE idGalaxie nom

Ce schéma modélise les planètes, chaque planète se trouvant dans un système précis, lui même se trouvant dans une galaxie précise (par exemple la planète terre se trouve dans le système solaire qui se trouve dans la voie lactée). Ce qui est intéressant, c’est de voir ce qui se passe au niveau relationnel. Vous remarquerez que pour PLANETE, la clé étrangère est double pour bien faire le lien avec SYSTEME (qui possède une clé primaire double). GALAXIE(idGalaxie, nom) idGalaxie : clé primaire SYSTEME(idGalaxie, idSysteme, nom) idGalaxie, idSysteme : clé primaire idGalaxie : clé étrangère en réf. à idGalaxie de GALAXIE PLANETE(idGalaxie, idSysteme, idPlanete, nom) idGalaxie, idSysteme, idPlanete : clé primaire idGalaxie, idSysteme : clé étrangère en réf. à (idGalaxie, idSysteme) de SYSTEME

Liens identifiants multiples En suivant la même logique, on peut imaginer des liens identifiants multiples, donc plusieurs liens identifiants partant de la même entité afin de récupérer plusieurs clés.

Séquence 2

Certains vont même encore plus loin et suppriment certaines associations en ne mettant aucune clé primaire dans l’entité faible et en ne gérant que des liens identifiants : cette solution n’est syntaxiquement pas fausse mais je ne la trouve pas du tout visuelle.

Le modèle conceptuel de données

Les liens identifiants sont très intéressants lorsqu’ils sont correctement utilisés. Cependant, ne cherchez pas à en mettre partout.

Page 29

9. Agrégation Comme le lien identifiant, l’agrégation est une notion introduite depuis Merise/2 (étudié dans la séquence suivante). Cependant, elle apporte une simplification dans la construction des schémas : voilà pourquoi elle est abordée dès maintenant. Il arrive parfois que pour créer une association, il soit nécessaire de récupérer les identifiants d’une autre association. Dit autrement, il existe des associations qui servent à associer non pas 2 entités (ou +) mais une entité et une association. Dans la représentation classique, la nouvelle association devait reprendre les liens directs de l’ancienne association, en ajoutant le lien vers la nouvelle entité. Voyons un exemple : Des vêtements sont vendus dans des tailles différentes avec un prix qui varie suivant la taille. Une facture peut concerner plusieurs vêtements : il faut bien sûr connaître à chaque fois la taille. Dans un premier temps, pour mémoriser le prix d’un vêtement, 2 informations sont nécessaires : le vêtement et sa taille.

8 2955 TG PA 00

VETEMENT idVetement description

VETEMENT_TAILLE

0,n

0,n

prix

TAILLE idTaille libellé

Maintenant, pour gérer la facture, il faut mémoriser les vêtements achetés sans oublier de préciser à chaque fois la taille. Une ligne de facture est cette fois une association entre FACTURE et VETEMENT_TAILLE. Dans Merise, il est normalement interdit de faire une association sur une autre association, du coup il faut reprendre tous les liens de l’ancienne association : VETEMENT idVetement description

FACTURE

VETEMENT_TAILLE

0,n

0,n

prix 0,n

0,n

0,n

TAILLE idTaille libellé

LIGNE_FACTURE quantité

idFacture date

Les relations qui ne concernent que la partie facture sont les suivantes : FACTURE (idFacture, date) idFacture : clé primaire LIGNE_FACTURE (idFacture, idVetement, idTaille, quantité) idFacture, idVetement, idTaille : clé primaire idFacture : clé étrangère en réf. à idFacture de FACTURE idVetement : clé étrangère en réf. à idVetement de VETEMENT idTaille : clé étrangère en réf. à idTaille de TAILLE

Séquence 2 Le modèle conceptuel de données

Page 30

Avec les nouvelles règles de Merise/2, une association qui porte sur une autre association est acceptée. Ce lien entre 2 associations est appelé une agrégation. Voici la représentation la plus officielle : VETEMENT idVetement description

0,n

VETEMENT_TAILLE prix

0,n

TAILLE idTaille libellé

0,n FACTURE idFacture date

0,n

LIGNE_FACTURE quantité

Cette représentation montre que l’association LIGNE_FACTURE est entre FACTURE et le groupe formé par VETEMENT, TAILLE et VETEMENT_TAILLE. Il est donc bien question d’une association entre FACTURE et l’association VETEMENT_TAILLE.

8 2955 TG PA 00

Cette fois, les relations qui en découlent sont un peu différentes et font ressortir ce lien qui n’apparaissait pas dans l’ancienne représentation : FACTURE (idFacture, date) idFacture : clé primaire LIGNE_FACTURE (idFacture, idVetement, idTaille, quantité) idFacture, idVetement, idTaille : clé primaire idFacture : clé étrangère en réf. à idFacture de FACTURE idVetement, idTaille : clé étrangère en réf. à (idVetement, idTaille) de VETEMENT_TAILLE

Jusque là, Merise ne symbolisait pas les liens sur les clés étrangères multiples. Avec l’agrégation, ce point est résolu. Pour représenter l’agrégation, suivant les sites et les livres, plusieurs variantes sont présentées. L’une d’elles me paraît moins lourde que la représentation officielle. C’est celle que j’ai tendance à utiliser. À vous de choisir la représentation que vous préférez mais encore une fois, vous devez savoir tout lire. VETEMENT idVetement description

0,n

VETEMENT_TAILLE prix

0,n

TAILLE idTaille libellé

0,n FACTURE idFacture date

0,n

LIGNE_FACTURE

Séquence 2

quantité

Certains pensent qu’il y a ambigüité sur le sens (qui récupère les clés de qui) : je n’en vois pas. C’est forcément l’association qui a le moins de liens directs qui récupère les clés de l’autre association.

Le modèle conceptuel de données

Page 31

10. Petit mémento du MCD Vous avez vu les outils du MCD. Il vous reste maintenant à apprendre à les manipuler correctement. Voici un ensemble de conseils et de cas de figures classiques. Prenez le temps de bien assimiler chaque point abordé, illustré à chaque fois par un exemple (repéré par le petit bonhomme). Cette partie est la plus importante du cours.

Comment reconnaître une entité ? Une entité est la représentation du réel : personne, lieu, objet… Pour repérer une entité, il faut se demander si l’on a affaire à un ensemble d’informations liées par un sens commun et clairement identifiable par un seul attribut. Rappelezvous aussi que les attributs doivent être en dépendance fonctionnelle élémentaire et directe avec l’identifiant de l’entité. Pour chaque film, il sera possible de connaître l’ensemble des informations importantes : titre du film, résumé succinct, durée, année de sortie.

8 2955 TG PA 00

Les attributs donnés dans le sujet sont : titre, résumé, durée et année. Ces attributs décrivent tous un film, d’où la création de l’entité FILM pour les contenir. Il reste à trouver l’identifiant : aucun des attributs ne peut jouer le rôle d’identifiant (même le titre car 2 films peuvent avoir le même titre), d’où l’ajout d’un idFilm qui contiendra un numéro séquentiel généré automatiquement.

FILM idFilm titre résumé durée année

FILM (idFilm, titre, résumé, durée, année) idFilm : clé primaire

Comment trouver l’identifiant d’une entité ? Il arrive que plusieurs attributs puissent jouer le rôle d’identifiant pour une entité. Vous avez alors a priori le choix. Cependant, évitez de prendre un attribut existant comme identifiant. Il est conseillé d’ajouter un attribut de type numéro séquentiel qui sera automatiquement géré et incrémenté par le système. Cela évite tout problème. Une personne possède un nom, une adresse, un téléphone et un numéro de Sécurité sociale.

Quels sont les attributs qui peuvent servir d’identifiants ? Séquence 2 Le modèle conceptuel de données

Page 32

telephone : un téléphone identifie de façon unique une personne, mais c’est une information non stable (la personne peut changer de numéro) donc non PERSONNE fiable. idPersonne numSS : un numSS est unique et stable, mais on n’est pas à l’abri d’une nom erreur de saisie ou de traitement, de plus c’est un numéro volumineux adresse (les identifiants doivent être les plus légers possible car ils peuvent être telephone numSS repris en particulier dans les associations). La meilleure solution est donc d’ajouter un attribut idPersonne de type numéro séquentiel. Cela n’empêchera pas le fait de pouvoir accéder aux personnes par leur numSS ou leur téléphone.

Comment reconnaître une association ? Il existe 3 cas possibles d’associations.

1er cas : l’association "normale" Si un ou plusieurs attributs nécessitent plusieurs informations élémentaires pour y accéder, il faut créer une association pour contenir ces attributs. Dans une commande, pour chaque article commandé, il faut connaître la quantité.

La quantité dépend de la commande mais aussi de l’article. Il faut donc créer une association entre COMMANDE et ARTICLE pour accéder à la quantité commandée. COMMANDE idCommande date

8 2955 TG PA 00

1,n

LIGNE_COMMANDE qteCommandée

ARTICLE 0,n

idArticle nomArticle prix

COMMANDE (idCommande, date) idCommande : clé primaire ARTICLE (idArticle, nomArticle, prix) idArticle : clé primaire LIGNE_COMMANDE (idCommande, idArticle, qteCommandée) idCommande, idArticle : clé primaire idCommande : clé étrangère en réf. à idCommande de COMMANDE idArticle : clé étrangère en réf. à idArticle de ARTICLE

2e cas : l’association "vide" ("non porteuse") Un lien entre entités peut parfois être nécessaire non pas pour accéder à une nouvelle information mais pour permettre des traitements qui nécessitent ce lien.  n livre peut être écrit par plusieurs auteurs : il est nécessaire de pouvoir éditer la liste des U livres d’un auteur précis.

LIVRE

AUTEUR_LIVRE

1,n

idLivre titre

0,n

AUTEUR idAuteur nom

Cette fois l’association ne contient rien, cependant elle est nécessaire pour pouvoir faire le lien entre LIVRE et AUTEUR. Séquence 2

LIVRE (idLivre, titre) idLivre : clé primaire AUTEUR (idAuteur, nom) idAuteur : clé primaire AUTEUR_LIVRE (idLivre, idAuteur) idLivre, idAuteur : clé primaire idLivre : clé étrangère en réf. à idLivre de LIVRE idAuteur : clé étrangère en réf. à idAuteur de AUTEUR

Le modèle conceptuel de données

Page 33

3e cas : la CIF Lorsqu’il existe une dépendance fonctionnelle entre 2 identifiants, celle-ci va se traduire par une association particulière : la CIF Un livre est classé dans un thème précis.

LIVRE idLivre titre

1,1

0,n

THEME idTheme libellé

Les thèmes sont recensés dans une entité, donc il suffit de créer un lien entre LIVRE et THEME pour récupérer le thème du livre. Ce lien se traduit ensuite par une clé étrangère. LIVRE (idLivre, titre, idTheme) idLivre : clé primaire idTheme : clé étrangère en réf. à idTheme de THEME THEME (idTheme, libellé) idTheme : clé primaire

8 2955 TG PA 00

Comment transformer une association en entité ? Avant de voir dans quel cas il est conseillé de transformer une association en entité, voyons techniquement comment cela peut se faire. Voici un extrait de schéma : HOTEL idHotel nom adresse

DATE dateDebutLoc 0,n 0,n FACTURE dateFinLoc

0,n NUMCHAMBRE

1,1

0,n

0,n

numChambre

Séquence 2 Le modèle conceptuel de données

Page 34

CLIENT idClient nom

Avant de donner les règles de transformation, il est nécessaire d’expliquer un peu ce schéma. Ici, la facture est repérée par 3 informations : l’hôtel concerné, le numéro de chambre (sachant qu’un même numéro de chambre peut se retrouver dans plusieurs hôtels) et la date de début de location de la chambre. Ces 3 informations étant suffisantes pour repérer une facture précise, il suffit ensuite de mettre dans l’association les informations restantes (dateFinLoc et le client, auquel on accède par clé étrangère). Remarquez aussi NUMCHAMBRE qui est lié à autre chose dans le schéma… (vous l’avez compris, ce schéma n’est pas en Merise/2) Une association FACTURE n’étant pas une bonne idée, transformons-la en entité. Voici les règles précises de transformation d’une association en entité : •

l’identifiant de la nouvelle entité est un nouvel identifiant ;

•

les attributs simples de l’association restent des attributs simples dans la nouvelle entité ;

•

les CIF partant de l’association restent des CIF partant de la nouvelle entité ;

•

les liens directs qui entourent l’association se transforment en CIF partant de la nouvelle entité (sauf en cas de lien direct vers une entité "vide" non utilisée dans le reste du schéma : dans ce cas l’entité disparaît et son identifiant se transforme en attribut simple dans la nouvelle entité). HOTEL idHotel nom adresse

FACTURE 0,n

1,1

0,n NUMCHAMBRE numChambre

8 2955 TG PA 00

1,1

idFacture dateDebutLoc dateFinLoc 1,1

CLIENT

0,n 0,n

idClient nom

Quand transformer une association en entité ? La transformation d’une association en entité est normalement à éviter car l’identifiant d’une association représente une information parlante puisque c’est un ensemble d’identifiants provenant d’entités existantes. Cependant, pour éviter les erreurs, donc quand vous n’êtes pas sûrs de vous, prenez l’option de transformer une association en entité : •

si vous remarquez que votre association possède trop de liens directs et que vous n’arrivez pas à les minimiser (à partir de 4 liens, posez-vous de sérieuses questions) ;

•

si vous pensez qu’il faut une association mais que vous n’arrivez pas à déterminer les liens directs

 n trajet de bus est identifié par un chauffeur, un bus, un horaire (identique pour chaque U jour), un jour et une ligne de bus. CHAUFFEUR idChauffeur nom

0,n

0,n TRAJET

0,n

0,n

HORAIRE

0,n DATE

heureDeb

date

BUS idBus dateAchat

Séquence 2

LIGNE idLigne libellé

Le modèle conceptuel de données

Page 35

L’erreur classique consiste à réaliser le schéma précédent. Face à un tel cas, soit vous trouvez un nombre minimum de liens, soit vous transformez TRAJET en entité.

1re solution : minimiser les liens Comment déterminer un trajet précis ? •

date+ligne : ce n’est pas suffisant car une ligne effectue plusieurs trajets par jour.

•

date+ligne+horaire : là, sans ambiguïté, pour une même ligne, un jour précis et pour un horaire précis, il ne peut pas y avoir plusieurs bus ni plusieurs chauffeurs.

Autres associations de clés possibles dans ce cas : •

date+horaire+bus : pour un jour et un horaire précis, un bus ne peut pas se partager pour gérer plusieurs trajets, donc ça marche.

•

date+horaire+chauffeur : pour un jour et un horaire précis, un chauffeur ne peut pas se partager pour gérer plusieurs trajets, donc ça marche aussi.

Cependant je préfère la première proposition (date+ligne+horaire). Pourquoi ? Parce que c’est la plus stable : on peut être amené à changer de bus au dernier moment (panne) ou à changer de chauffeur (malade) mais pas changer de ligne.

8 2955 TG PA 00

CHAUFFEUR idChauffeur nom

0,n

0,n 1,1

1,1

BUS idBus dateAchat

TRAJET 0,n

HORAIRE

0,n

0,n DATE

heureDeb

LIGNE idLigne libellé

date

2e solution : transformer l’association en entité CHAUFFEUR idChauffeur nom

BUS 0,n 1,1

TRAJET idTrajet date heureDeb

Page 36

idBus dateAchat

1,1 0,n

Séquence 2 Le modèle conceptuel de données

0,n

1,1

LIGNE idLigne libellé

Là bien sûr, il n’y a plus de problème ! Cependant cette solution doit être choisie seulement quand vous avez peur de faire une erreur. Vous avez sans doute aussi compris qu’en utilisant les liens identifiants, ce genre de cas se posera nettement moins souvent.

Comment vérifier la syntaxe du schéma conceptuel de données ? La syntaxe respecte les règles du modèle relationnel et les règles graphiques du MCD. Il suffit donc de contrôler que tout est conforme. Dans un premier temps, contrôlez que les attributs sont bien en dépendance fonctionnelle élémentaire et directe avec leur identifiant respectif. Ensuite, voici quelques conseils à suivre. Ces points sont visuellement faciles à contrôler : as de CIF vers une entité temporelle : une CIF est là pour aller chercher plus O Pd’informations dans une autre entité, ce qui ne peut être le cas dans une entité temporelle qui est vide (excepté la clé) et qui va disparaître au niveau des relations. FACTURE idFacture total

8 2955 TG PA 00

1,1

0,n

DATE date

d’association avec un seul lien direct : une association possède au moins O 2Pasattributs en identifiant, donc au moins 2 liens directs. LIVRE idLivre titre

1,n

AUTEUR_LIVRE auteur

as de lien direct entre 2 entités : (sauf dans le cas d’un héritage, ce qui est O Ptotalement différent) 2 entités ne peuvent être liées que par une association (quel que soit le type d’association : une CIF par exemple). Cette erreur, pour une raison obscure, est assez classique. LIVRE idLivre titre

1,n

THEME idTheme libellé

Comment vérifier la sémantique d’un schéma conceptuel de données ? Je n’ai aucune recette de cuisine à vous proposer excepté utiliser vos neurones. Le mieux est de relire attentivement le sujet pour contrôler étape par étape si votre schéma répond aux attentes.

Comment déduire les relations à partir du schéma ? Vous commencez à connaître le principe de traduction du schéma conceptuel de données en relations normalisées. Voici un résumé de toutes les règles à connaître. •

Les entités temporelles et numéro (appelées entités "vides") disparaissent.

•

Les entités normales (possédant des attributs ou dont l’identifiant, s’il est seul, comporte une information qui ne peut être générée automatiquement) se transforment en relation : l’identifiant devient la clé primaire de la relation.

•

Toutes les associations (excepté les CIF) se traduisent en relation dont les clés primaires sont récupérées avec les liens directs de l’association (ces clés primaires sont aussi étrangères lorsqu’elles sont clés primaires dans une autre relation).

•

Les CIF (cardinalité 1,1 et éventuellement 0,1) disparaissent et se traduisent par une clé étrangère dans la relation qui est du côté de la cardinalité 1,1 (éventuellement 0,1).

•

Les attributs simples (des entités ou des associations) sont recopiés dans les relations.

•

Les entités filles (sous-types) récupèrent la clé primaire de l’entité mère, cette clé étant aussi étrangère.

Séquence 2 Le modèle conceptuel de données

Page 37

8 2955 TG PA 00

Exercice 3 Écrivez séparément les relations issues de ces 2 schémas (en nouvelle notation). CHAUFFEUR idChauffeur nom

0,n

0,n 1,1

0,n

HORAIRE

1,1

TRAJET

0,n

0,n DATE

heureDeb

HOTEL

0,n

Le modèle conceptuel de données

idHotel nom adresse

idBus dateAchat

LIGNE idLigne libellé

date

Séquence 2

BUS

DATE dateDebutLoc 0,n

0,n FACTURE

CHAMBRE

Page 38

0,n

dateFinLoc

NUMCHAMBRE numChambre

0,n

1,1

CLIENT 0,n

idClient nom

Quelques cas de figure courants des schémas conceptuels de données La première partie du mémento vous a présenté les bases pour construire correctement un schéma conceptuel de données. Vous allez maintenant aborder plusieurs cas de figures classiques, pour vous habituer à ces types de problèmes. Chaque cas est illustré par un exemple. Vous trouverez plusieurs exercices en fin de séquence : n’hésitez pas à régulièrement revenir sur ce mémento pour vous aider.

Choix de l’identifiant Vous avez vu que pour les entités, il faut favoriser les identifiants internes automatiquement gérés par le système. Pour les associations, le problème se pose plutôt au niveau du choix des liens directs. Reprenons toutes ces notions à travers un exemple :  n enfant (n°insee, nom) parle plusieurs langues (libellé). Il faut connaître l’ordre des lanU gues pour chaque enfant.

8 2955 TG PA 00

Vous pourriez prendre comme identifiant d’enfant son n°insee mais c’est une mauvaise idée : même si ce numéro est stable, il est trop long (n’oubliez pas qu’un identifiant peut être utilisé ensuite comme clé étrangère) et dès qu’il y a intervention humaine (saisie de ce numéro), il peut y avoir des erreurs. C’est le même problème pour le libellé de la langue qui est forcément unique mais il est préférable d’identifier la langue avec un numéro automatique. Voici une première solution de schéma, sans utiliser les identifiants internes : ENFANT n°insee nom

LANGUE PARLEE

0,n

ordre

0,n

LANGUE libellé

Voici le résultat en extension : LANGUE

ENFANT n°insee

nom

libellé

2990506080010

DUPONT

Anglais

1010283090040

BERNARD

Allemand

1001213092040

DURAND

Espagnol

…

…

… Séquence 2

LANGUE PARLEE n°insee

libelle

ordre

2990506080010

Anglais

1

2990506080010

Allemand

2

2990506080010

Espagnol

3

1010283090040

Allemand

1

1001213092040

Anglais

1

1001213092040

Espagnol

2

…

Le modèle conceptuel de données

Page 39

…

Remarquez bien que dans LANGUE_PARLEE, la reprise des identifiants de ENFANT et LANGUE force à recopier les n°insee et les libellés des langues. Au niveau place ce n’est pas optimisé. Voici la solution avec des numéros internes : ENFANT idEnfant n°insee nom

0,n

LANGUE PARLEE ordre

0,n

LANGUE idLangue libellé

8 2955 TG PA 00

La représentation en extension donne ceci, pour le même exemple : ENFANT

LANGUE

idEnfant

n°insee

nom

idLangue

libellé

1

2990506080010

DUPONT

1

Anglais

2

1010283090040

BERNARD

2

Allemand

3

1001213092040

DURAND

3

Espagnol

…

…

…

LANGUE PARLEE idEnfant

idLangue

ordre

1

1

1

1

2

2

1

3

3

2

2

1

3

1

1

3

3

2

… Séquence 2 Le modèle conceptuel de données

Page 40

…

Et là vous vous dites : "le tableau précédent était peut-être plus lourd mais plus facile à comprendre". Mais là vous ne raisonnez pas en informaticien : le but est de stocker des données pour ensuite les traiter avec un programme. Par programme, on sait facilement trouver le nom ou le numéro d’insee de l’enfant dont l’identifiant est 1. Idem pour la langue. Donc cette seconde solution est nettement plus légère et efficace. Voici les relations qui en découlent : ENFANT (idEnfant, n°insee, nom) idEnfant : clé primaire LANGUE (idLangue, libellé) idLangue : clé primaire LANGUE_PARLEE (idEnfant, idLangue, ordre) idEnfant, idLangue : clé primaire idEnfant : clé étrangère en réf. à idEnfant de ENFANT idLangue : clé étrangère en réf. à idLangue de LANGUE

Une autre solution est possible : décider de mettre l’ordre de la langue au niveau de la clé primaire. Voici le résultat en utilisant un lien identifiant : ENFANT

LANGUE_PARLEE

(1,1)

0,n

idEnfant n°insee nom

ordre

1,1 LANGUE idLangue libellé

0,n

Cette fois, les langues parlées sont directement numérotées par enfant. Voici le résultat au niveau des relations :

8 2955 TG PA 00

ENFANT (idEnfant, n°insee, nom) idEnfant : clé primaire LANGUE (idLangue, libellé) idLangue : clé primaire LANGUE_PARLEE (idEnfant, ordre, idLangue) idEnfant, ordre : clé primaire idEnfant : clé étrangère en réf. à idEnfant de ENFANT idLangue : clé étrangère en réf. à idLangue de LANGUE

Quelle est la meilleure solution finalement ? Dans ce cas, il n’y en a pas une meilleure que l’autre. Les 2 ont un avantage et un inconvénient. La première solution évite d’attribuer 2 fois la même langue à un même enfant (puisque la clé primaire de LANGUE_PARLEE doit être unique) mais, si ce n’est pas correctement géré par programme, on peut par erreur attribuer 2 fois le même numéro d’ordre à un même enfant, ce qui serait faux. La seconde solution inverse le problème : elle évite d’avoir 2 fois le même numéro d’ordre pour un même enfant mais, si ce n’est pas correctement géré par programme, on peut par erreur attribuer 2 fois la même langue à un même enfant, ce qui serait aussi faux. Donc dans ce cas, a priori il n’y a pas de solution idéale. Cependant il arrive souvent qu’une solution soit meilleure que l’autre : il faudra savoir faire les bons choix.

CIF "porteuse" ou "non porteuse" ? Vous avez vu qu’une façon de symboliser les CIF est l’utilisation d’un petit rond (c’est la méthode que j’utilise de préférence). Cette représentation a le double avantage de vous permettre de repérer facilement les CIF et aussi d’éviter l’erreur qui consiste à mettre un attribut dans la CIF (là, vous n’avez pas la place, donc la question ne se pose pas). En effet, puisque la CIF ne se traduit pas par une relation, il n’est a priori pas logique de mettre un attribut dedans. En réalité, les choses sont nettement plus nuancées. Essayons de le comprendre à travers un exemple :

Séquence 2 Le modèle conceptuel de données

Page 41

Un étudiant doit choisir obligatoirement une option et il faut mémoriser à quelle date il l’a choisie.

Voici le schéma qui parait logique : ETUDIANT idEtudiant nom dateChoixOpt

OPTION 1,1

0,n

idOption libellé

Puisqu’il n’y a qu’une option possible, la date de choix de l’option peut être directement mise dans l’entité ETUDIANT : ETUDIANT (idEtudiant, nom, dateChoixOpt, idOption) idEtudiant : clé primaire idOption : clé étrangère en réf. à idOption de OPTION OPTION (idOption, libellé) idOption : clé primaire

Mais certains puristes diront : "la date du choix de l’option n’a de raison d’exister que par rapport au choix de l’option donc elle doit être portée par l’association". Du coup on représente la CIF sous forme d’une association classique, ce qui donne :

8 2955 TG PA 00

OPTION

ETUDIANT

CHOIX_OPTION

1,1

idEtudiant nom

dateChoixOpt

0,n

idOption libellé

Tout ça pour pas grand-chose puisqu’au niveau des relations, la cardinalité 1,1 se traduisant de toute façon par une clé étrangère, CHOIX_OPTION disparaît et son contenu est naturellement transféré dans ETUDIANT. Voyons ce qui se passe pour le cas d’une cardinalité 0,1 :

 n étudiant peut choisir au maximum une option et, s’il en choisit une, il faut mémoriser U à quelle date il l’a choisie. On obtient normalement le schéma suivant : ETUDIANT idEtudiant nom dateChoixOpt

Séquence 2

OPTION 0,1

0,n

idOption libellé

Il est identique au précédent excepté la cardinalité 0,1 car un étudiant peut ne pas choisir d’option. Dans ce cas, l’attribut dateChoixOpt va rester vide. Les attributs vides n’étant généralement pas très bien vus, on pourrait préférer la représentation suivante :

Le modèle conceptuel de données

ETUDIANT idEtudiant nom

Page 42

0,1

CHOIX_OPTION dateChoixOpt

OPTION 0,n

idOption libellé

Mais que faire au niveau relationnel ? Traduire le 0,1 par une clé étrangère et migrer dateChoixOpt dans la relation ETUDIANT, ou créer une relation CHOIX_OPTION puisque dateChoixOpt ne sera rempli que lorsqu’une option est choisie. Il faut bien avoir conscience que les 2 solutions sont possibles. Dans ce cas, la première me paraît la meilleure : c’est un peu lourd de créer une relation supplémentaire juste pour éviter un simple attribut vide. On peut parfois être confronté à des cas plus difficiles à trancher. En conclusion, pour limiter au maximum les erreurs, je vous conseille de ne jamais placer d’attributs dans les associations qui portent une cardinalité 1,1 ou 0,1 et, pour éviter cette erreur, le mieux est encore de toujours représenter ce type d’associations avec le petit rond. Cependant, n’oubliez pas que vous devez être capable d’interpréter toutes les représentations.

8 2955 TG PA 00

Notion d’historique Gérer un historique suppose que l’on désire garder des informations dans le temps. Il impose l’intervention d’une entité temporelle (ou d’un attribut temporel en identifiant, dans le cas d’une solution utilisant un lien identifiant).  e but est de mémoriser les locations des films avec, à chaque fois, la date de location et la L date de retour. Il faut aussi savoir qui a loué le film. Ce cas a déjà été vu. Il y a juste le client à ajouter. FILM

LOCATION

0,n

idFilm titre

0,n

dateRetour

DATE dateLocation

1,1 CLIENT

0,n

idClient nom

Attention, quand vous utilisez une entité temporelle, c’est forcément pour créer une association et cette entité ne peut pas contenir autre chose qu’un identifiant de type temporel (il ne peut pas y avoir d’attribut simple dedans). Voici l’erreur classique que l’on retrouve parfois : FILM idFilm titre

CLIENT idClient nom

LOCATION

0,n

0,n

Séquence 2 Le modèle conceptuel de données

DATE dateLocation dateRetour

Page 43

1,1 0,n

Ceci est une énormité. Pourquoi ? Vous faites une entité DATE qui comporte comme identifiant une dateLocation et comme attribut simple une dateRetour. Cela signifie que, quelle que soit la location, une dateLocation donne toujours la MEME dateRetour. Donc tous les clients qui font un emprunt FILM LOCATION le 12/02 doivent ramener le film (1,1) 0,n emprunté le 14/02… idFilm dateLocation Il faut bien comprendre le rôle d’une entité temporelle : elle apporte juste un identifiant temporel mais n’a pas de vie propre puisqu’elle est vouée à disparaître dans le schéma relationnel. Du coup la représentation avec un lien identifiant facilite les choses et limite les erreurs :

titre

dateRetour 1,1

CLIENT idClient nom

0,n

8 2955 TG PA 00

Au niveau relationnel, le résultat est le même que la solution précédente (celle qui était juste, bien sûr). FILM (idFilm, titre) idFilm : clé primaire CLIENT (idClient, nom) idClient : clé primaire LOCATION (idFilm, dateLocation, dateRetour, idClient) idFilm, dateLocation : clé primaire idFilm : clé étrangère en réf. à idFilm de FILM idClient : clé étrangère en réf. à idClient de CLIENT

"Sortir" ou non des informations d’une entité Vous allez parfois vous poser la question "dois-je laisser cette information sous forme d’attribut ou dois-je la sortir et créer une entité ?". Les informations doivent être sorties dans 2 cas : • si elles risquent de se répéter et/ou que des recherches peuvent porter dessus ; • si elles sont issues d’une liste déterminée.

 n livre comporte les renseignements suivants : titre, résumé, nombre de pages, auteur et U thème (il existe une liste de thèmes déterminée). Qu’est-ce qui va rester comme attribut simple et qu’est-ce qui va sortir de l’entité LIVRE ? Séquence 2 Le modèle conceptuel de données

Page 44

Titre, résumé et nombre de pages : ces informations sont simples et ne concernent que ce livre. Il n’y a aucun intérêt de les sortir en créant une autre entité. Thème : pas d’ambiguïté puisqu’il est question d’une liste déterminée de thèmes. Donc une entité THEME doit être créée. Auteur : ce n’est pas faux de mettre auteur en attribut simple de LIVRE et suivant les traitements qu’il faudra faire, ce sera peut-être la solution la plus simple. Mais il y a de grandes chances que cette information se répète (plusieurs livres d’un même auteur) et ce ne serait pas étonnant que des traitements portent sur l’auteur (recherche des livres d’un auteur) donc il paraît plus judicieux de sortir cette information.

AUTEUR idAuteur nom

THEME idTheme libellé

0,n

1,1

idLivre titre résumé nbPages 1,1

0,n

Voici donc la solution adoptée. Voici les relations correspondantes : AUTEUR (idAuteur, nom) idAuteur : clé primaire THEME (idTheme, libellé) idTheme : clé primaire LIVRE (idLivre, titre, résumé, nbPages, idAuteur, idTheme) idLivre : clé primaire idAuteur : clé étrangère en réf. à idAuteur de AUTEUR idTheme : clé étrangère en réf. à idTheme de THEME

8 2955 TG PA 00

LIVRE

Double CIF La double CIF représente la nécessité d’obtenir 2 informations provenant d’une même entité. Dans ce cas, pour une meilleure lisibilité, si la CIF est représentée sous forme d’un rond, son rôle est tout de même marqué dedans ou à côté.

Un voyage comporte une date, un nombre de jours, une ville de départ et une ville d’arrivée. Voici l’erreur classique à ne pas faire : VILLE DEPART 0,n VOYAGE idVoyage date nbJours

idVilleDépart nom

1,1 1,1 0,n

VILLE ARRIVEE idVilleArrivée nom

Cette représentation supposerait que certaines villes sont toujours des villes de départ, et d’autres toujours des villes d’arrivées. Ou alors, toutes les villes sont en double, dans départ et arrivée, ce qui n’est pas plus malin. Il est évident qu’il ne faut faire qu’une entité VILLE. Ce sont les CIF qui vont permettre de choisir la ville de départ et la ville d’arrivée. VOYAGE idVoyage date nbJours

1,1 1,1

départ arrivée

0,n 0,n

Séquence 2 Le modèle conceptuel de données

Page 45

VILLE idVille nom

Voici les relations correspondantes (où les noms donnés aux clés étrangères doivent être parlants) : VILLE (idVille, nom) idVille : clé primaire VOYAGE (idVoyage, date, nbJours, idVilleDepart, idVilleArrivee) idVoyage : clé primaire idVilleDepart : clé étrangère en réf. à idVille de VILLE idVilleArrivee : clé étrangère en réf. à idVille de VILLE

Association réflexive L’association réflexive est nécessaire lorsqu’on a besoin de lier une information avec ellemême. Ce lien peut être nécessaire pour accéder à une nouvelle information, ou juste pour obtenir des "couples" nécessaires pour les traitements. Là encore, il ne faut surtout pas séparer l’entité en 2.

8 2955 TG PA 00

Il faut enregistrer les distances entre les villes. Voici l’erreur à ne pas faire : VILLE DEPART idVilleDépart nom

0,n DISTANCE distance

VILLE ARRIVEE

0,n

idVilleArrivée nom

Pour les mêmes raisons que tout à l’heure (dans la partie "double CIF"), c’est une grave erreur de séparer les villes en 2 entités. Voici la solution :

Séquence 2

VILLE

Le modèle conceptuel de données

Page 46

0,n

DISTANCE

idVille nom

distance 0,n

Lorsque cela paraît nécessaire, il est possible de mettre des noms de rôle sur chaque lien direct. Ici, le nom de l’association est suffisamment explicite. Voici le résultat au niveau relationnel (où cette fois, ce sont les clés primaires qui doivent être renommées pour être plus explicites et de toute façon pour éviter d’avoir 2 attributs avec le même nom, ce qui n’est pas possible) : VILLE (idVille, nom) idVille : clé primaire DISTANCE (idVilleDepart, idVilleArrivee, distance) idVilleDepart, idVilleArrivee : clé primaire idVilleDepart : clé étrangère en réf. à idVille de VILLE idVilleArrivee : clé étrangère en réf. à idVille de VILLE

CIF réflexive Le cas de la CIF réflexive est nettement plus rare et, dans tous les cas, ne peut pas porter une cardinalité minimum à 1 (sinon la réflexivité n’aurait pas de fin) donc les cardinalités seront 0,1 d’un côté et 0,n (ou 0, une valeur déterminée) de l’autre. Contrôlez bien que vous n’êtes pas en présence d’une association réflexive (la confusion est classique). Les CIF réflexives traduisent des structures en forme d’arbre (où l’on retrouve un antécédent mais plusieurs successeurs).

8 2955 TG PA 00

 n composant ne rentre dans la fabrication que d’un seul autre composant, mais il peut être U fabriqué avec plusieurs composants. 0,n COMPOSANT idComposant nom 0,1 Voici la relation correspondante : COMPOSANT (idComposant, nom, idCompPere) idComposant : clé primaire idCompPere : clé étrangère en réf. à idComposant de COMPOSANT

CIF et association entre 2 entités Il est tout à fait possible d’avoir une CIF et une association entre 2 mêmes entités. Chacune (la CIF et l’association) joue son rôle. Dans ce cas, la CIF décrit généralement (mais pas toujours) un cas particulier de l’association. Elle pourrait donc éventuellement se traduire par un attribut booléen dans l’association. Mais cette dernière solution, tout en étant juste, est plus lourde et moins visuelle que la précédente. Comme dans le cas de la double CIF, il est souvent conseillé de nommer la CIF pour que le schéma soit plus parlant.

 ne formation peut être animée par plusieurs formateurs dont l’un d’eux est responsable de U la formation.

Séquence 2 Le modèle conceptuel de données

Page 47

Voici la première solution, avec un booléen : FORMATION idFormation titre date

ANIMATEUR

1,n

0,n

responsable

FORMATEUR idFormateur nom

Cette solution a un inconvénient : pour chaque couple "formation/formateur" dans animateur, il faut préciser si c’est le responsable ou non, alors qu’il n’y a qu’un responsable. La solution suivante est plus visuelle et évite ce problème : 1,1

FORMATION idFormation titre date

0,n

responsable

ANIMATEUR

0,n

FORMATEUR 0,n

idFormateur nom

8 2955 TG PA 00

Voici les relations correspondantes : FORMATEUR (idFormateur, nom) idFormateur : clé primaire FORMATION (idFormation, titre, date, idResp) idFormation : clé primaire idResp : clé étrangère en réf. à idFormateur de FORMATEUR ANIMATEUR (idFormation, idFormateur) idFormation, idFormateur : clé primaire idFormation : clé étrangère en réf. à idFormation de FORMATION idFormateur : clé étrangère en réf. à idFormateur de FORMATEUR

CIF partant d’une association Vous avez vu ces CIF partant d’associations à travers plusieurs exemples précédents. Pourquoi en parler maintenant ? Qu’ont-elles de particulier ? En fait, rappelons qu’une CIF est une association (même si elle est un peu particulière). Avant l’ajout de la notion d’agrégation avec Merise/2 (c’est-à-dire le fait de permettre de relier une association directement à une autre), la plupart des utilisateurs de la méthode Merise partaient du principe que, la CIF étant une association, il n’était pas permis de la faire partir directement d’une autre association. Cette règle m’a toujours gênée car une CIF se traduit par une clé étrangère et je ne vois pas pourquoi une relation issue d’une association n’aurait pas le droit d’avoir une clé étrangère.

Séquence 2 Le modèle conceptuel de données

De toute façon, maintenant la question ne se pose plus puisque, depuis Merise/2, cette interdiction est levée. Attention, cependant, vous pouvez très bien trouver dans des sujets une représentation sous forme d’agrégation pour symboliser une CIF (lorsque celle-ci est symbolisée par une association classique). 1re représentation (qui me semble être la plus visuelle) : FILM

Page 48

idFilm titre

LOCATION

0,n

dateRetour

0,n

DATE dateLocation

1,1

CLIENT

0,n

idClient nom

2e représentation (que vous devez savoir au moins lire) : FILM idFilm titre

CLIENT idClient nom

8 2955 TG PA 00

LOCATION

0,n

dateRetour

1,1 0,n

LOUE

0,n

DATE dateLocation

Facturation classique La facturation est un des cas les plus classiques rencontrés dans les sujets de gestion. Bien sûr il existe plusieurs variantes suivant les contextes, cependant, il existe 2 grandes catégories de facturation. 1re catégorie de facturation : chaque article n’apparaît qu’une fois C’est le cas le plus classique de facturation. Un article peut être acheté en plusieurs exemplaires, mais n’apparaît que sur une seule ligne de la facture. Voici le schéma correspondant : FACTURE idFacture date

1,n

LIGNE_FACTURE qteCommandée

ARTICLE 0,n

idArticle nomArticle prix

Voici les relations correspondantes : FACTURE (idFacture, date) idFacture : clé primaire ARTICLE (idArticle, nomArticle, prix) idArticle : clé primaire LIGNE_FACTURE (idFacture, idArticle, qteCommandee) idFacture, idArticle : clé primaire idFacture : clé étrangère en réf. à idFacture de FACTURE idArticle : clé étrangère en réf. à idArticle de ARTICLE

Séquence 2

2e catégorie de facturation : chaque article peut apparaître plusieurs fois C’est par exemple le cas de la facturation dans un restaurant : sur le ticket, les articles sont dans l’ordre de la commande, donc il peut y avoir une boisson en début de repas, qui est ensuite recommandée en cours de repas. Un même article peut non seulement être commandé plusieurs fois, mais peut aussi apparaître sur des lignes différentes de la facture. Le schéma précédent ne marche plus car LIGNE_FACTURE a pour identifiant idFacture+idArticle. L’identifiant devant être unique, on ne pourra pas avoir plusieurs fois le même article sur des lignes différentes de la facture. Du coup, il faut utiliser les numéros de lignes de la facture.

Le modèle conceptuel de données

Page 49

Voici la solution : FACTURE idFacture date

1,n

LIGNE_FACTURE qteCommandée 1,1 0,n

0,n

NUMLIGNE numLigne

ARTICLE idArticle nomArticle prix

8 2955 TG PA 00

La version avec lien identifiant est plus légère : FACTURE idFacture date

0,n

(1,1)

LIGNE_FACTURE numLigne qteCommandée 1,1

ARTICLE

0,n

idArticle nomArticle prix

Voici les relations correspondantes : FACTURE (idFacture, date) idFacture : clé primaire ARTICLE (idArticle, nomArticle, prix) idArticle : clé primaire LIGNE_FACTURE (idFacture, numLigne, qteCommandee, idArticle) idFacture, numLigne : clé primaire idFacture : clé étrangère en réf. à idFacture de FACTURE idArticle : clé étrangère en réf. à idArticle de ARTICLE

Gestion des âges Séquence 2 Le modèle conceptuel de données

Page 50

Le but est d’utiliser les attributs qui nécessitent le moins de mises à jour possible. Par exemple, dans le cas de l’âge (ou de l’ancienneté dans une entreprise), il ne faut bien évidemment pas utiliser cette donnée comme attribut mais la remplacer par la date de naissance. La date de naissance est une donnée fixe et l’âge pourra être récupéré par simple calcul. Ceci est donc valable pour toutes les données qui peuvent être obtenues par un calcul sur une autre donnée plus stable.

Gestion d’une liste La liste d’informations peut être gérée de 2 façons suivant les besoins : – elle est traduite par un simple attribut lorsque le contenu de cette liste n’est pas homogène et ne fera l’objet d’aucun traitement sur une partie des informations, mais toujours sur la liste complète ; – elle est traduite par une association pour récupérer l’ensemble des informations de la liste dans une autre entité.  Pour chaque film, on désire connaître le titre, la durée, la liste des intervenants composant le générique du film (scénaristes, animateurs 3D, spécialistes du son…) et la liste des acteurs. Il doit être possible de faire des recherches par acteur. Très nettement, la liste des acteurs doit être gérée sous forme d’association. En revanche, la liste des intervenants, donc le générique, semble une information non homogène et ne subissant qu’un traitement dans sa globalité. FILM idFilm titre durée générique

8 2955 TG PA 00

0,n

ACTEUR_FILM

0,n

ACTEUR idActeur nom

La transitivité Dans certains cas, il existe plusieurs chemins pour accéder à la même information. Il y a alors une transitivité et le chemin le plus court doit normalement être supprimé. Attention, suivant l’ordre des traitements, certaines transitivités se justifient.

 ne formation est animée par un formateur et ne concerne qu’une spécialité. Un formateur U n’est spécialisé que dans une spécialité. FORMATEUR

0,n

idFormateur nom

1,1 0,n

FORMATION

1,1

SPECIALITE idSpécialité libellé

idFormation titre

1,1 0,n

Le lien entre FORMATION et SPECIALITE est en trop puisqu’on peut obtenir la spécialité de la formation en passant par le formateur. Mais attention, cet exemple a été choisi pour son ambiguïté. En effet, si le choix du formateur se fait après avoir créé la formation et donc en fonction de la spécialité attendue pour la formation, alors il est nécessaire de mémoriser la spécialité de la formation indépendamment du formateur.

Séquence 2

Donc, quand vous tombez sur un cas de transitivité, avant de spontanément supprimer le lien qui semble "en trop", posez-vous la question de son utilité.

Les paramètres et entités indépendantes

Le modèle conceptuel de données

Page 51

Pour finir, voici un cas que vous rencontrerez très rarement dans les sujets traditionnels, mais que vous serez amené à gérer dans les cas réels de gestion de projets. Les schémas semblent relier toutes les entités d’une façon ou d’une autre. Si vous avez des entités "isolées", vous avez toutes les raisons de vous poser des questions. Cependant, il existe 2 cas où les entités peuvent effectivement être isolées. 1er cas : les entités indépendantes Elles sont très rares mais elles existent. On les retrouve en particulier dans certains cas de gestion d’intervalles.

 our des achats entre 50 et 100 €, 15 % de remise, de 101 à 130 €, 18 %, etc. Il faut P connaître la remise accordée pour chaque facture. Cette entité ne peut être reliée à rien. Tout se fera par calcul. Par rapport au montant de la facture, une recherche sera effectuée dans REMISE pour trouver dans quelle plage de valeurs se trouve le montant. Une fois la plage trouvée, il suffira de récupérer le pourcentage de remise pour l’appliquer au montant.

REMISE valeurDebut valeurFin remise

8 2955 TG PA 00

2e cas : les paramètres Ce sont des données utiles au développement de l’application mais indépendantes du schéma conceptuel de données. Les paramètres sont normalement tous regroupés dans une même "entité", sans clé primaire et comportant une valeur par attribut (donc un seul tuple). Ils représentent généralement des informations sur l’entreprise qui est concernée par l’informatisation.  ans l’application, il sera nécessaire d’utiliser le nom et l’adresse de l’entreprise, ainsi que D son numéro SIRET. Les informations peuvent être stockées dans un fichier texte, XML ou être mémorisées dans une table ne contenant qu’une seule ligne, sans clé primaire. Chaque attribut contient une information unique.

PARAMETRE nomE adresseE siret

11. Exercices récapitulatifs de premier niveau

Séquence 2 Le modèle conceptuel de données

Maintenant, il faut faire des exercices. Surtout ne faites pas l’erreur de vous limiter à juste quelques exercices ou de simplement survoler la correction. Il est indispensable de tous les aborder et de passer du temps à chercher. Jusqu’à maintenant vous avez appris à interpréter et compléter des schémas existants : là vous allez devoir construire des schémas, ce qui est nettement plus complexe. Cependant, les exercices sont progressifs, donc faites-les dans l’ordre et prenez le temps de bien lire, dans la correction, toutes les explications. Les premiers exercices n’abordent pas directement la construction complète de schémas, mais vont vous permettre d’être confrontés à plusieurs cas classiques. Attention, malgré le titre, certains exercices ne sont pas si faciles.

Page 52

Exercice 4 Voici les relations qui permettent de gérer la fabrication de jouets du père noël : JOUET(idJouet, nom, idCatégorie#) CATEGORIE(idCatégorie, libellé) ENFANT(idEnfant, nom, age, adresse) COMMANDE(idEnfant#, idJouet#)

Dessiner le SCD à l'origine de ces relations (sans oublier les cardinalités). Réécrire les relations en suivant les nouvelles normes. Préciser toutes les règles de gestion qui découlent de ces relations (dit autrement : justifier chaque cardinalité). L'auteur de ces relations hésitait entre l'attribut "age" et l'attribut "dateDe-Naisssance" dans l'entité "ENFANT". Dire s'il a fait le bon choix, en justifiant la réponse. Compléter d'une autre couleur le MCD en tenant compte des remarques suivantes : • il existe plusieurs ateliers où sont fabriqués les jouets ; • un jouet n'est fabriqué que dans un atelier ; • des lutins fabriquent les jouets : un lutin n'est affecté qu'à un atelier. Finalement on modifie certaines règles de gestion : • un jouet peut être de plusieurs catégories différentes ; • un enfant peut commander plusieurs exemplaires du même jouet ; • un enfant doit préciser l'ordre d'importance des jouets qu'il commande. Refaire le SCD en repartant des relations du début du sujet et en tenant compte de ces nouvelles règles.

8 2955 TG PA 00

Exercice 5 Voici un ensemble de relations : DOSSIER (idDossier, dateOuverture, idClient) idDossier : clé primaire CLIENT (idClient, nom, adresse, tel) idClient : clé primaire FICHE_DOSSIER (idDossier, numFiche, dateFiche, description) idDossier, numFiche : clé primaire idDossier : clé étrangère en réf. à idDossier de DOSSIER

a) Dessiner le SCD à l'origine de ces relations (en version Merise/2). b) Comment appelle-t-on le lien qui unit FICHE_DOSSIER à DOSSIER ? c) Pourquoi numFiche n'est pas aussi en clé étrangère dans la relation FICHE_DOSSIER ? d) Dire si les affirmations suivantes sont vraies : 1. une fiche n'appartient qu'à un seul dossier ; 2. un dossier peut comporter plusieurs fiches ; 3. une fiche peut concerner plusieurs clients ; 4. un client peut posséder plusieurs fiches.

Exercice 6 Voici un ensemble de relations : MEDECIN(idMedecin, nom) idMedecin : clé primaire PATIENT(idPatient, nom, adresse, tel) idPatient : clé primaire MUTUELLE(idMutuelle, nom, adresse) idMutuelle : clé primaire MUTUELLE_PATIENT(idPatient, idMutuelle) idPatient, idMutuelle : clé primaire idPatient : clé étrangère en réf. à idPatient de PATIENT idMutuelle : clé étrangère en réf. à idMutuelle de MUTUELLE RV(idPatient, date, heure_deb, heure_fin, idMedecin) idPatient, date : clé primaire idPatient : clé étrangère en réf. à idPatient de PATIENT idMedecin : clé étrangère en réf. à idMedecin de MEDECIN OPERATION(idPatient, date, numOperation, détail) idPatient, date, numOperation : clé primaire idPatient, date : clé étrangère en réf. à (idPatient, date) de RV

Séquence 2 Le modèle conceptuel de données

Page 53

Exemples d'opérations : soin de la dent n°14, pose d'une couronne sur la dent n°3, détartrage… Les opérations ont donc lieu lors d'un rendez-vous. Attention, chaque opération ne concerne qu'un rendez-vous et donc un patient précis. a) C  onstruire le schéma conceptuel des données à l'origine de ces relations (vous trouverez dans la correction la version classique et la version Merise/2). b) • • • •

 épondre aux questions suivantes en justifiant chaque réponse : R Un patient peut-il consulter plusieurs médecins ? Plusieurs opérations peuvent-elles se faire durant un seul rendez-vous ? Un rendez-vous peut-il concerner plusieurs médecins ? Un patient peut-il prendre plusieurs rendez-vous le même jour ?

8 2955 TG PA 00

c) S i le cabinet ne comportait qu'un seul médecin, quelle modification faudrait-il apporter au schéma ? (Expliquer la réponse en clair, sans modifier le schéma) d) O  n vous donne de nouvelles règles de gestion. Modifier le schéma, dans une autre couleur, pour tenir compte de ces règles : • tous les patients ont une (et une seule) mutuelle ; • il faut mémoriser les dates de congés des médecins (plusieurs congés par médecin).

Exercice 7 On veut gérer une bibliothèque et ses prêts de livres. Beaucoup de livres de la bibliothèque existent en plusieurs exemplaires. Certains exemplaires peuvent être prêtés, d'autres ne sont qu'en consultation sur place (autorisation en sortie = O ou N). Il est possible de faire des recherches de livres sur le titre, mais aussi sur les thèmes du livre (un livre peut être classé dans plusieurs thèmes), sur l'auteur (sachant qu'un livre n'a qu'un auteur…). On connaît l'état de chaque exemplaire. La bibliothèque propose aussi ses livres à la vente. Le prix varie d'un livre à l'autre, mais reste fixe pour un même livre. On connaît le nom, l'adresse et le n° de téléphone des clients. Séquence 2 Le modèle conceptuel de données

Page 54

L'historique des prêts doit être mémorisé, avec la date de prêt et la date de retour ainsi que le client qui est responsable de la location. Si un livre n'est pas disponible, une personne peut le réserver : elle sera prévenue par téléphone dès qu'un exemplaire est disponible. Un livre ne peut pas être prêté plusieurs fois le même jour. a) D'après les explications suivantes, corriger le schéma (4 erreurs) :

8 2955 TG PA 00

b) L'association PRET n'est pas satisfaisante : elle est constituée de trop de liens directs. Un des liens pourrait être transformé en CIF : lequel et pourquoi ? c) L e schéma n'exploite pas les possibilités de Merise/2. Refaire le schéma en tenant compte de ces règles (et de la remarque issue du b) ). d) Écrire les relations issues du dernier schéma.

Exercice 8 Un magasin de micro-ordinateurs possède un catalogue qui recense tous ses articles (nom, prix de vente, catégorie). Le catalogue est classé par catégorie. Pour chaque article, il connaît plusieurs fournisseurs (nom, adresse, tel). Chaque fournisseur propose l'article en question à un prix particulier. Dessiner le SCD et écrire les relations correspondantes.

Exercice 9 Un patient (nom, adresse, téléphone) possède un dossier qui lui est propre et qui le suit lors de tous ses passages à l'hôpital. À chaque passage du patient, on note la date d'entrée, le motif du passage et la date de sortie (sachant qu'il ne peut pas y avoir plusieurs "entrées" le même jour pour un même patient). Dessiner le SCD et écrire les relations correspondantes.

Exercice 10

Séquence 2 Le modèle conceptuel de données

Page 55

Une agence organise des séjours linguistiques. Un séjour comporte les informations suivantes : la langue concernée (parmi la liste des langues proposées par l'agence), la date de départ et la date de retour, la ville de départ et la ville d'arrivée. Les tarifs sont établis, entre autres, en fonction des distances entre les villes : il ne faut donc pas mémoriser les tarifs mais les distances. Dessiner le SCD et écrire les relations correspondantes.

Exercice 11 Le but est de mémoriser les informations sur les clients d'une société : raison sociale et n° Siret pour les entreprises, nom et prénom pour les particuliers, adresse, n° de téléphone pour tous. Le fax est plus répandu en entreprise mais certains particuliers en ont aussi. Les entreprises sont classées par catégorie. Dessiner le SCD et écrire les relations correspondantes.

8 2955 TG PA 00

Exercice 12 Les droïdes de Géonosis Vous travaillez pour le vice-roi Nute Gunray qui s'est réfugié sur la planète Géonosis pour suivre de près la fabrication d'une armée de droïdes. Vous allez devoir vous occuper d'une partie de l'informatisation de la gestion des droïdes (fabrication et utilisation). Votre prédécesseur n'ayant pas donné satisfaction, il a "disparu". Il avait commencé une étude de besoins qui l'avait conduit à écrire quelques relations dans le but de créer une base de données. Vous avez retrouvé une partie de ses travaux. Voici les relations retrouvées (écrites suivant les anciennes règles d'écritures) : DROIDE (n°droide, nom, date_fabrication, date_mise_en_service, n°typedroide#) TYPEDROIDE (n°typedroide, libellé) ARME (n°arme, nom, puissance, portée) ARME_DROIDE (n°droide#, n°arme#)

Question 1 : Dessinez le schéma conceptuel des données correspondant à ces relations. Nute Gunray avait donné, avant l'écriture de ces relations, un ensemble de règles que vous trouverez en annexe 1. Séquence 2 Le modèle conceptuel de données

Page 56

Question 2 : Vous devez préciser pour chaque règle, si elle a été effectivement respectée avec les relations précédentes. Les droïdes devant être utilisés pour des batailles, Nute Gunray avait donné aussi quelques règles qui ont été traduites par un SCD que vous trouverez en annexe 2. Question 3 : Écrivez les relations normalisées (en respectant les nouvelles règles d'écriture) qui découlent de ce schéma conceptuel de données. Ce SCD (de l'annexe 2) est incomplet, plusieurs règles n'ont pas été traduites : a) Q  uand une bataille se terminera, il faudra mémoriser la date (date fin) et l'issue (qui est le gagnant : les séparatistes ou la république ?) b) Il est nécessaire de connaître la liste des lieux recensés sur chaque planète (chaque lieu possède un nom, une description, une longitude et une latitude). c) L es batailles sont classées par type (un seul type par bataille). Exemple : attaque au sol, bombardement aérien… Question 4 : Apportez les modifications sur le SCD pour respecter ces règles.

8 2955 TG PA 00

Annexe 1 Pour chaque règle, cochez VRAI si les relations du début du sujet respectent cette règle, cochez FAUX dans le cas contraire.

VRAI FAUX

a) U  n droïde possède une date de fabrication et une date de mise en service

¨

¨

b) U  n droïde n'appartient qu'à un seul type (droïdekas, droïde de combat, droïde de soutien, droïde médical tripode, astro-droïde…)

¨

¨

c) Un type de droïde possède une durée de vie

¨

¨

d) C  haque droïde fabriqué est numéroté par rapport à son type (1er droïde de combat, 2e droïde de combat… 1er droïdekas, 2e droïdekas, 3e droïdekas…)

¨

¨

e) P  our chaque arme, il faut connaître son nom, sa puissance et sa portée

¨

¨

f) C  haque type de droïde peut manipuler certaines armes, il faut savoir lesquelles

¨

¨

g) P  our chaque arme, la quantité de munitions stockable varie suivant le type de droïde

¨

¨

h) Il faut connaître la quantité fabriquée de chaque arme

¨

¨

Séquence 2 Le modèle conceptuel de données

i) U  n droïde a un nom qui lui est propre et qui le qualifie en plus de son type et de son numéro (ex : R2D2, R4G9 sont les noms de 2 astro-droïdes)

¨

¨

j) Il faut mémoriser la date de désactivation d'un droïde

¨

¨

Page 57

Annexe 2

8 2955 TG PA 00

Exercice 13 Vous travaillez au FBI avec Mulder sur les affaires non classées. Pour faciliter la gestion des dossiers, une informatisation est préconisée. Suite à une analyse du fonctionnement du service de Mulder, un premier informaticien a commencé à construire un schéma relationnel (présenté ici suivant les anciennes normes d'écriture) : Affaire (n°affaire, date_debut, date_cloture, lieu, description) Personne (n°personne, nom, adresse, informations) PersonneAffaire (n°affaire#, n°personne#) LienAffaire (n°affaire1#, n°affaire2#, n°raison#) Raison (n°raison, libellé)

Remarque : n°affaire1 et n°affaire2 sont des attributs qui contiennent des valeurs correspondant à n°affaire dans la relation Affaire. LienAffaire permet de savoir pourquoi 2 affaires sont éventuellement liées. A) Construire le schéma conceptuel de données issu de ces relations. Mulder vous a demandé d'informatiser le suivi détaillé des investigations sur les affaires non classées. Pour cela il vous a donné un ensemble de règles (annexe 1) que vous avez tenté de traduire dans un SCD (annexe 2). B) É crire l'extrait de schéma relationnel portant sur les objets INVESTIGATION, INTERVENANT, AGENT et AFFAIRE issus du schéma conceptuel de données de l'annexe 2 (vous devez obligatoirement respecter les nouvelles normes d'écriture).

Séquence 2

C) P  our chaque affirmation de l'annexe 1, préciser si elle est respectée ou non dans le SCD de l'annexe 2.

Le modèle conceptuel de données

D) L e SCD de l'annexe 2 ne respectant pas correctement toutes les règles de l'annexe 1, il vous est demandé de refaire complètement le SCD en respectant toutes les règles de l'annexe 1 (et uniquement ces règles là).

Page 58

Annexe 1 : les affirmations

8 2955 TG PA 00

VRAI FAUX

a) Les  investigations sont identifiées par l'affaire concernée et la date de l'investigation (il ne peut donc pas y avoir plusieurs investigations le même jour pour la même affaire, cependant il peut y avoir plusieurs investigations le même jour pour des affaires différentes). ¨

¨

b) Une investigation est affectée à un ou deux agents.

¨

¨

c) P  our chaque investigation, il faut mémoriser la durée, le lieu, un commentaire précis de la raison de l'investigation, ainsi que le résultat.

¨

¨

d) P  our chaque investigation, il faut connaître le ou les éventuels transports utilisés (il existe une liste précise de transports possibles). ¨

¨

e) P  our chaque investigation, il faut connaître le ou les éventuel(s) hôtel(s) utilisé(s) (il existe une liste d'hôtels avec leur nom, adresse, téléphone).

¨

¨

f) U  ne investigation donne éventuellement lieu à des frais de remboursement (s'il y a eu déplacements et/ou nuits d'hôtel). Ces remboursements sont réalisés en fonction des frais réels donc des factures fournies : le montant total, qu'il faut mémoriser, est ensuite divisé par le nombre d'agents. La date de remboursement n'est pas forcément la même pour chaque agent.

¨

g) U  ne affaire est numérotée et comporte une date d'ouverture, de clôture, un commentaire, un résultat et un agent qui sera responsable du suivi de l'affaire.

¨ ¨

¨

h) Il faut pouvoir joindre facilement chaque agent : on mémorise donc, en plus de leur nom, leur n° de portable et leur adresse email. ¨ ¨ i) M  ême si une investigation est rattachée à une affaire, elle concerne parfois secondairement plusieurs autres affaires : il faut savoir lesquelles.

¨ ¨

j) P  our chaque transport utilisé pour une investigation, il faut mémoriser le kilométrage, et pour chaque hôtel utilisé pour une investigation, il faut mémoriser le nombre de nuits.

¨ ¨

Annexe 2 : le SCD

Séquence 2 Le modèle conceptuel de données

Page 59

8 2955 TG PA 00

12. Exercices récapitulatifs de second niveau Ces exercices sont des sujets où vous devez réaliser des SCD complets et assez conséquents. Certains exercices sont issus de sujets officiels. Faites-les aussi avec beaucoup d’attention et en y passant le temps nécessaire. Aucun exercice ne doit être mis de côté car chacun permet de consolider des notions particulières.

Exercice 14 Vous devez informatiser une salle de musculation. Chaque personne doit s'inscrire pour accéder à la salle. Les renseignements suivants sont nécessaires pour gérer les adhérents : nom, adresse, téléphone, poids initial, taille, sports pratiqués. Pour chaque sport on désire connaître le nom du sport et le niveau de l'adhérent (débutant, confirmé, professionnel). La date d'inscription doit aussi être enregistrée (pour le paiement annuel de la cotisation). On veut ensuite pouvoir suivre l'évolution d'un adhérent. Chacune de ses visites doit être numérotée (1re visite de M. Dupont, 2e visite de...) et doit comporter les renseignements suivants : date et heure de la visite, durée et, pour chaque appareil utilisé, nombre de séries et valeur des poids utilisés. Séquence 2 Le modèle conceptuel de données

Pour chaque appareil, il doit être possible d'obtenir le poids minimum, le poids maximum et la liste des muscles qui travaillent. Il sera, entre autres, possible d'effectuer les traitements suivants : – liste des appareils qui font travailler un muscle donné ; – liste des adhérents classés par sport pratiqué.

Page 60

Dessiner le SCD. Une petite précision est apportée : attention, le poids utilisé est le même au cours d'une série mais peut varier d'une série à une autre (pendant une visite). Apporter la modification nécessaire sur le schéma précédent et écrire les relations correspondantes.

Exercice 15 Un restaurant décide de développer un système de livraison de pizzas à domicile. Vous êtes chargé de l’informatisation de cette activité en répondant aux deux objectifs principaux : – obtenir des livraisons les plus rapides possible ; – garder le plus d’informations possibles sur les clients pour les fidéliser. Les commandes se font par téléphone. Un client appelle et demande une ou plusieurs pizzas. Soit il précise les noms exacts qu’il aura pris sur le prospectus du restaurant, soit il précise vaguement ce qu’il désire et l’opératrice devra le conseiller. Un client peut, bien sûr, commander plusieurs pizzas identiques ou différentes. Chaque pizza est caractérisée par son nom, la description de ses ingrédients principaux (simplement le nom des ingrédients, comme jambon, fromage, sans les quantités...). Chaque pizza est proposée avec 3 tailles différentes (mini, normale ou maxi). Le client doit donc aussi préciser la taille de chacune des pizzas commandées. Le prix d’une pizza dépend bien sûr de la pizza choisie et de sa taille. En fait, le prix de la mini est toujours 20 % moins élevé que la normale, et le prix de la maxi 20 % plus élevé. 8 2955 TG PA 00

Pour chaque commande, l’opératrice doit noter le nom du client, son adresse précise et son numéro de téléphone. Une fois la commande passée, les pizzas sont aussitôt fabriquées puis livrées dans les délais les plus brefs. Plusieurs livreurs s’occupent de ce travail. Pour chaque commande, il faut mémoriser le livreur qui s'en est occupé (en cas de réclamation). Afin de personnaliser l’accueil téléphonique des clients et de les fidéliser au maximum, on désire garder le détail de toutes leurs précédentes commandes dans le but d’afficher rapidement ces informations. L’opératrice pourra donc tout de suite proposer au client ses anciens choix (pour donner l’impression qu’elle se souvient de lui) ainsi que ses coordonnées. Si c’est un nouveau client, elle le saura donc tout de suite et pourra éventuellement le conseiller. La fidélisation des clients se fait aussi à travers des réductions. Celles-ci fonctionnent très simplement : sur l’ensemble des commandes, la 10e pizza est gratuite. Le paiement de la commande peut se faire soit directement au téléphone (carte bleue), soit à la livraison (chèque ou liquide). Il faut aussi mémoriser si la commande a été payée. Faire le SCD et écrire les relations correspondantes.

Exercice 16 Ce sujet est plus long et contient des annexes : lisez bien tout l'ensemble avant de démarrer et récupérez bien toutes les informations qui permettront d'obtenir les annexes. L'étude proposée concerne la gestion des passagers et de leurs bagages voyageant sur la compagnie aérienne TRANSAIR. Cette compagnie dessert uniquement des villes de France métropolitaine. L'enregistrement

Séquence 2 Le modèle conceptuel de données

Page 61

Un passager désirant faire appel à la compagnie pour son voyage doit se munir d'un billet (annexe 1). Avec ce billet, le passager se présente au comptoir d'enregistrement de l'aéroport de départ deux heures avant le décollage. L'agent de la compagnie lui remet contre l'un des volets du billet une carte d'embarquement mentionnant son numéro d'enregistrement pour le vol. Cette carte lui permettra l'accès à bord de l'appareil. Le passager conserve la souche du billet. S'il possède des bagages, chacun de ceux-ci est pesé, étiqueté et conduit dans la soute de l'avion. Pour chaque bagage enregistré, un talon d'étiquette est collé sur la souche du billet. À l'issue des opérations d'enregistrement, le passager est donc en possession de sa carte d'embarquement et de la souche de son billet, éventuellement complétée d'autant de talons d'étiquette qu'il y a de bagages enregistrés. Le passager peut alors embarquer. Des exemples de ces différents documents sont présentés en annexe (carte d'embarquement : annexe 2, étiquette bagage : annexe 3, talon d'étiquette bagage : annexe 4). Le voyage Un billet correspond à un voyage entre deux villes de France métropolitaine. Pour se rendre à sa destination finale, un passager peut emprunter successivement plusieurs vols (Lille-Orly, Orly-Toulouse par exemple). Cela signifie qu'un ou plusieurs changements d'avion peuvent être nécessaires. Dans ce cas, le passager n'a qu'un seul billet et enregistre ses éventuels bagages une seule fois, à l'aéroport de départ. Ceux-ci l'accompagnent tout au long du voyage.

8 2955 TG PA 00

Par contre, à chaque changement d'appareil, le passager doit se présenter au comptoir d'enregistrement muni de la souche de son billet pour recevoir une nouvelle carte d'embarquement. Les vols Un vol est une liaison directe entre deux aéroports, toujours les mêmes. Un aéroport possède un code et un nom (annexe 5). Chaque vol est identifié par un numéro. Un vol a lieu à certaines dates, une seule fois par jour, et possède toujours le même horaire. La liaison entre deux aéroports peut être assurée plusieurs fois par jour par des vols différents. Un exemple de liste des vols assurés par TRANSAIR à une date donnée est présenté en annexe 6. Dessiner le SCD et écrire les relations correspondantes.

Séquence 2 Le modèle conceptuel de données

Page 62

8 2955 TG PA 00

Séquence 2 Le modèle conceptuel de données

Page 63

Exercice 17 Gestion des terrasses (extrait du sujet officiel 2006) Annexe à utiliser : Tarif des terrasses année 2005 Le service emplacements de la mairie de P. est responsable de la gestion de l’occupation du domaine public par les établissements et les commerces de la ville. Cette occupation du domaine public concerne notamment l'installation de terrasses de bars ou restaurants. En fin d’année, le service emplacements émet les avis des sommes à payer à destination des établissements (restaurants ou bars) exploitant des terrasses. L’élaboration de ces documents est basée sur les éléments suivants :

8 2955 TG PA 00

– Les terrasses déclarées, pour l’année en cours, par les établissements. Une terrasse est caractérisée par un type (terrasse permanente, terrasse semi-permanente, terrasse d’été) et une surface. Une terrasse dépend d’un seul établissement. À titre d’exemple, le tableau qui suit présente les terrasses dont l’occupation est déclarée par l’établissement "Machicoulis" (dont le code est 52) au cours de l’année 2005. Code terrasse

Type

Surface en m2

Date installation

521

Terrasse permanente

4

01/01/2005

522

Terrasse d’été

4

15/05/2005

– Les tarifs en vigueur, votés par le conseil municipal en début d’année, sont consignés dans un arrêté fourni en annexe. Le tarif appliqué pour une terrasse dépend de son type et de la zone de tarification de l’établissement. Le territoire de la ville est partagé en zones qui déterminent la tarification applicable en fonction de la localisation de l’établissement. Ainsi, le coût d’une terrasse pour un bar éloigné du centre ville est très inférieur à celui d’une terrasse d’un bar situé dans un quartier piétonnier. Au titre de l’année 2005, le "Machicoulis" (qui se trouve en zone A) devra acquitter la somme de (126,50 * 4) + (42,97 * 4) soit 677,88 €. Dans le cas de l’installation d’une terrasse en cours de période tarifaire, la somme à payer sera calculée au prorata du temps restant jusqu’à la fin de cette période. Séquence 2 Le modèle conceptuel de données

Page 64

– Les établissements occupant une terrasse située sur le domaine public. Chaque établissement est identifié par un code. Il est décrit par une appellation commerciale et une adresse. Il est rattaché à une seule zone de tarification. – Les personnes physiques ou morales exploitant les établissements et redevables des sommes à payer. Il n’est pas rare qu’un exploitant ait la responsabilité de plusieurs établissements. Pour chaque exploitant, le service emplacements connaît son nom (ou raison sociale), son adresse et son téléphone. Dans le cas où un établissement change d’exploitant en cours d’année, la somme à payer est répartie entre l’ancien et le nouvel exploitant au prorata des temps d’occupation. Il est possible qu’un exploitant cède un établissement puis en reprenne l’exploitation sur une autre période. Le "Machicoulis" a été exploité en 2004 par Pierre Jucas de janvier à mars, puis par la société Govry d’avril à juin puis de nouveau par Pierre Jucas jusqu’à la fin de l’année. Pierre Jucas va donc être facturé de l’occupation de la terrasse permanente pour 274 jours et la société Govry pour 91 jours. La société Govry va être facturée de l’occupation de la terrasse d’été pour 46 jours (du 15 mai à fin juin) et Pierre Jucas pour 77 jours (de début juillet au 15 septembre). Dans la perspective du développement d’une application spécifique, cette étude de l’existant est complétée par le recensement des fonctionnalités que devra offrir le futur logiciel. Le résultat de cette étape fait apparaître les quatre besoins suivants : – tenir à jour la liste des établissements et notamment pouvoir retrouver tous les exploitants successifs d’un établissement. Cette exigence est nécessaire pour calculer les sommes à payer par chaque exploitant ayant eu la responsabilité d’un établissement au cours de l’année ;

8 2955 TG PA 00

– t enir à jour la liste des terrasses. Seules les terrasses de l’année en cours devront être gérées par l’application ; –e  nregistrer en début d’année les nouveaux tarifs. L’historique de la base tarifaire n’est pas souhaité ; – éditer les avis des sommes à payer.

Travail à faire Concevoir le schéma entité-association représentant les besoins informationnels de la gestion des terrasses. Annexe : Tarif des terrasses année 2005 Mairie de P. - Service Emplacements - Cellule 118 - Mél : [email protected]

OCCUPATION COMMERCIALE DU DOMAINE PUBLIC   TARIFS  2005  

> Terrasse permanente (du 1er janvier au 31 décembre - 365 jours) Zone

Tarif (en € / m2)

A

126,50

B C

106,36 74,74

> Terrasse semi-permanente (du 1er avril au 31 octobre - 214 jours) Zone

Tarif (en € / m2)

A B

74,16 62,36

C

43,82

> Terrasse d'été (du 15 mai au 15 septembre - 123 jours) Zone A

Tarif (en € / m2) 42,97

B

36,14

C

25,39

T e r r a s s e s

Séquence 2 Le modèle conceptuel de données

Page 65

2 0 0 5

8 2955 TG PA 00

Exercice 18 Cas triathlète (sujet officiel 2000) Le CDTVL souhaite disposer d’un logiciel de gestion des triathlons qu’il organise. Les informations à prendre en compte sont décrites ci-dessous. Les triathlètes Chaque triathlète possède une licence délivrée par la Fédération française de triathlon. Le numéro de licence identifie un sportif et reste identique d’une année à l’autre. Il existe deux types de licence : licence "club" et licence "individuelle". En effet, un triathlète n’est pas obligatoirement membre d’un club. Un sportif qui n’est pas membre d’un club s’inscrit aux compétitions de manière individuelle. Les deux modèles de licence se présentent ainsi : Licence Club

Licence individuelle

Séquence 2 Le modèle conceptuel de données

Page 66

Remarques : – L a date de 1re licence est la date à laquelle le triathlète a été licencié pour la première fois. – Si un triathlète change de statut (membre d’un club devenant individuel par exemple), son numéro de licence reste inchangé.

8 2955 TG PA 00

Tout triathlète appartient à une catégorie d’âge (benjamin, minime, cadet, junior, senior, vétéran). Chaque catégorie est identifiée par un code. Chaque catégorie est caractérisée par l’âge auquel elle débute et l’âge auquel elle se termine. Tous les clubs ayant des triathlètes inscrits à des compétitions organisées par le CDTVL sont répertoriés. Un club est identifié par un numéro et possède un nom, une adresse et un numéro de téléphone. Il est également nécessaire de connaître le nom des entraîneurs du club : ces entraîneurs sont toujours des triathlètes membres du club qu’ils entraînent. Les triathlons Un triathlon est une compétition ouverte à toutes les catégories d’âge. Il existe plusieurs types de triathlon, chaque type de triathlon se distingue des autres par les distances à parcourir dans les trois sports de base (natation, cyclisme et course à pied). Chaque type de triathlon est identifié par un code et possède une désignation. À titre d’exemple, le code TROP correspond à un triathlon olympique. Chaque triathlon possède un numéro, un nom, un type et se déroule en un lieu précis à une date donnée. Par exemple, le triathlon numéro 12, nommé "Course folle", se déroule à Orléans le 26 juin 2000 ; il s’agit d’une compétition de type TROP. Le déroulement de la compétition Dès que l’organisation d’un triathlon a été publiée par le CDTVL, les triathlètes peuvent s’y inscrire. À l’inscription, un numéro de dossard est attribué au triathlète pour la compétition et sa date d’inscription est mémorisée. Une inscription est identifiée par le numéro du triathlon concerné suivi du numéro de dossard attribué au triathlète. Les inscriptions sont closes 15 jours avant la date de la compétition. Le jour du triathlon, le CDTVL recense les participants à la course. Il arrive qu’un sportif inscrit ne se présente pas, il est alors déclaré forfait. Après le déroulement de la course, les résultats obtenus par chaque participant sont relevés :

Séquence 2 Le modèle conceptuel de données

Page 67

– classement du concurrent dans la catégorie (premier, second…) ; – temps réalisé dans les différentes épreuves (natation, course cycliste, course à pied). Le cas des abandons en cours d’épreuve sort du cadre de cette étude et n’est donc pas à prendre en compte. Les contrôles anti-dopage Dans le cadre de la lutte anti-dopage, la fédération nationale expérimente de nouveaux contrôles à l’issue d’une compétition de triathlon. Un contrôle consiste à vérifier l’absence de produits dopants dans le sang. Un produit dopant est identifié par un code, possède un libellé et un taux maximum autorisé par millilitre de sang. Lors d’un triathlon, certains triathlètes, identifiés par leur numéro de dossard, sont contrôlés. On effectue donc des prélèvements sanguins et un laboratoire indépendant analyse ces prélèvements. Dès qu’elles sont connues, on enregistre les mesures établies par le laboratoire pour chacun des produits dopants recherchés.

Travail à faire Présenter le schéma entité-association permettant de prendre en compte l'ensemble des règles de gestion relatives à la gestion des triathlètes, l'organisation des triathlons et les contrôles anti-dopage.

8 2955 TG PA 00

Exercice 19 Cas Thali (sujet officiel 2008) THALI est un centre de thalassothérapie situé au bord de l’Océan Atlantique. Il accueille des clients en cure toute l’année et dispose d’un hôtel pour l’hébergement des curistes qui le souhaitent. THALI a choisi de fermer ses portes pendant trois mois pour rénover entièrement ses locaux, acquérir de nouveaux équipements et refondre son système d’information. Annexes à utiliser : 1A et 1B Les prestations THALI offre à ses clients deux types de prestation : des cures sur six jours et des weekends de soin. Son catalogue s’est enrichi au fil des années permettant aujourd’hui de proposer : – les cures bien-être, remise en forme, santé, amincissement, postnatale, anti-âge, santé du dos et santé des jambes ; – les week-ends détente et beauté-fraîcheur. Toutes les prestations sont caractérisées par une description qui met en évidence leurs vertus. Chaque prestation est identifiée par un code.

Séquence 2 Le modèle conceptuel de données

Page 68

Ces prestations se composent d’un certain nombre de soins tels le massage tonique, le massage anti-stress, le drainage lymphatique corps, le drainage lymphatique visage, le bain hydromassant, la douche abdominale, l’enveloppement de boues d’algues marines, etc. Chacun d’eux est identifié par un code et se caractérise par une durée estimée. Seules les cures sont caractérisées par un certain nombre d’objectifs qui sont codifiés ; certains objectifs sont communs à plusieurs cures. L’annexe 1A présente la cure bien-être avec sa description, ses objectifs et les soins prodigués. Les tarifs des prestations sont également présentés pour l’année 2008 ; l’ensemble des tarifs est conservé au minimum sur deux années. Pour certaines cures, une visite médicale est imposée. Il est également possible qu’une cure donne lieu à remboursement lorsqu’elle fait l’objet d’une prescription médicale. Des critères spécifiques ont été définis afin d’évaluer les bienfaits de chaque cure. Par exemple, pour la cure amincissement, codifiée AM55, les critères suivants ont été établis pour les bilans : tour de taille (AM551), tour de hanche (AM552) et tour de cuisse (AM553). L’hébergement Un hébergement en pension complète est proposé aux clients et aux personnes les accompagnants pendant les cures ou les week-ends. Comme pour les prestations de thalassothérapie, les prix varient en fonction de la saison et de l’année. Ils sont conservés au minimum sur deux années. Le tableau des tarifs pour 2008 est présenté dans l’annexe 1B.

Travail à faire À partir des informations fournies dans ce dossier et de l’annexe 1, construire le schéma entité-association relatif aux services proposés par le centre de thalassothérapie et leur tarification.

8 2955 TG PA 00

Annexe 1A : Cure "bien-être" Description Destiné à toute personne recherchant forme, vitalité et bien-être, ce programme va contribuer à un ressourcement général. Après une période d'activité intense, qu'elle soit d'ordre psychique, physique ou intellectuelle, le corps a besoin de retrouver son énergie. Dans cette cure, les soins à base d'eau de mer et d'algues seront privilégiés afin de vous faire profiter au maximum des oligo-éléments et vitamines qu'ils contiennent. Massages et relaxation seront également au programme pour vous apporter cette détente indispensable à une remise en condition optimale. Soins 3 massages normaux, 3 massages relaxants, 3 douches à affusion, 3 bains bouillonnants algués, 1 soin hydratant du visage, 3 enveloppements d’algues, 3 douches sousmarines, 3 bains hydromassants, 1 manucure et 1 soin des pieds. Objectifs • Ressourcement général. • Entretien d'un bon état de santé. Tarifs en euros de la cure “Bien-être” pour 2008 :

Séquence 2 Le modèle conceptuel de données

Page 69

Annexe 1B : Tarifs journaliers en euros de l'hébergement en pension complète pour 2008

Les tarifs diffèrent notamment selon la situation de la chambre (vue sur la mer, le jardin ou la rue).

8 2955 TG PA 00

Synthèse

synthèse rappelle les termes utilisés dans cette séquence mais ne peut O Cseette substituer à l'étude attentive de la séquence, en particulier de tous les cas exposés dans le mémento du MCD. MCD (Modèle Conceptuel de Données) : c'est un des modèles de la méthode Merise. Il permet une représentation graphique du modèle relationnel. Entité : représentation graphique d'une relation en 3NF dont la clé primaire n'est composée que d'un seul attribut élémentaire. L'entité est une représentation du réel (personne, chose, lieu…). Association : représentation graphique d'une relation en 3NF dont la clé primaire est composée d'au moins 2 attributs élémentaires. L'association permet de créer un lien entre plusieurs entités. CIF (Contrainte d'Intégrité Fonctionnelle) : elle traduit une dépendance fonctionnelle entre 2 clés primaires. C'est une association particulière qui se traduit par une clé étrangère dans le modèle relationnel. Séquence 2 Le modèle conceptuel de données

Page 70

Cardinalités : elles permettent d'exprimer le nombre minimum et maximum d'occurrences d'une entité par rapport à une autre (liées par une association). Héritage : il permet de représenter des sous-types d'entités afin de tenir compte de cas particuliers. Intégrité fonctionnelle : elle traduit une dépendance forte entre des objets. Les SGBDR gèrent généralement les intégrités fonctionnelles automatiquement dès que des clés étrangères sont définies, et limitent ainsi les erreurs de manipulations. Lien identifiant : il traduit une dépendance forte entre 2 entités, l'identifiant de l'entité faible est alors constitué de son propre identifiant + celui de l'entité forte. Il permet d'éliminer les entités "numéro" et la plupart des entités temporelles. Agrégation : elle offre une représentation visuelle d'une association sur une autre (elle reprend donc les identifiants d'une autre association).

8 2955 TG PA 00

Séquence 3

Extensions sous Merise/2 Cette séquence aborde l’ensemble des extensions apportées à la méthode Merise. Vous en connaissez certaines et vous allez en découvrir d’autres. Ces extensions sont couramment utilisées et vont vous servir pour aborder la programmation directement intégrée dans un SGBDR.

u Prérequis Avoir totalement acquis les connaissances abordées dans la séquence 2 : savoir construire un schéma conceptuel de données d’une certaine complexité.

u Capacités attendues en fin de séquence Savoir construire un schéma conceptuel de données complexe en intégrant les extensions de Merise/2 et plus particulièrement les contraintes.

u Contenu 1. Qu’est-ce que Merise/2 ....................................................................................... 72 2. Les sous-types sur association ........................................................................... 73 3. Les contraintes ..................................................................................................... 75 4. Exercices récapitulatifs ........................................................................................ 87 Page 71

Synthèse

8 2955 TG PA 00

.............................................................................. 107

8 2955 TG PA 00

1. Qu’est-ce que Merise/2 ? Vous avez pu apprécier l’intérêt d’utiliser une méthode d’analyse, en particulier la méthode Merise qui a été précédemment étudiée. Cette méthode vous a apporté, au niveau des données, les outils nécessaires pour optimiser l’organisation des informations qui sont ensuite enregistrées dans une base de données et exploitées dans une application. Tout en étant d’une grande efficacité, la méthode Merise s’avère incomplète ou inefficace dans certains domaines. Ces problèmes ont été résolus en apportant des compléments à la méthode d’origine. Ces compléments s’appellent des "extensions" et la nouvelle méthode s’appelle Merise/2. Vous avez déjà abordé certaines de ces extensions dans la séquence précédente et dans le cours 2949 "Exploitation d’un schéma de données", cependant elles sont toutes réexpliquées dans cette séquence. Cette séquence va donc vous présenter l’essentiel des extensions apportées au MCD.

Intérêt des extensions Les extensions ont différentes utilités : •

Certaines apportent une solution à des problèmes non résolus (les sous-types sur association). Pour le moment, il est possible de gérer des attributs spécifiques dans une entité, mais pas dans une association.

•

Certaines permettent de simplifier les formalismes un peu lourds (les agrégations et les liens identifiants). Comment relier directement 2 associations. Comment éliminer certaines entités spatio-temporelles...

•

Certaines permettent de visualiser des contraintes jusque là ignorées au niveau des données ou à peine mentionnées par des commentaires accompagnant le schéma (les contraintes). Par exemple : "Un salarié ne peut être à la fois animateur et participant à un même stage."

Séquence 3 Extensions sous Merise/2

Page 72

Vous avez déjà étudié en détail les liens identifiants et les agrégations. Ces deux notions ne seront donc pas revues. Pourquoi les avoir étudiées à l’avance ? Parce que ces 2 notions sont plutôt simples et surtout apportent une aide réelle à la construction d’un schéma plus lisible. Dans la suite de cette séquence, seuls les sous-types sur association et surtout les contraintes seront étudiées : deux notions totalement nouvelles pour vous. Cependant, dans la partie synthèse de la séquence, les liens identifiants et les agrégations sont rappelés car ils font partie de Merise/2. Voici tout de même deux exercices qui portent sur les liens identifiants et les agrégations, en guise de révision.

Exercice 1 Une agence de voyages organise des séjours à thème. Un séjour est repéré par une destination principale et une date (il ne peut pas y avoir 2 séjours différents pour une même destination et une même date). Les destinations possibles sont des villes, situées dans des pays. Pour chaque séjour, il faut mémoriser la durée en nombre de jours, le tarif, le type de séjour (historique, scientifique, sportif, festif, reposant...) ainsi que la liste des activités prévues pour le séjour. Chaque activité est numérotée par séjour (première activité du séjour, seconde activité du séjour...). Il faut mémoriser le nom de l’activité ainsi que son tarif (les activités sont souvent payantes). Il arrive que certaines activités soient découpées en sous-activités : il faut alors mémoriser l’ordre des sous-activités et leur nom. Suivant les séjours, certaines options sont proposées (chambre individuelle, pension complète...). Ces options peuvent être sélectionnées pour différents séjours. Construire le SCD correspondant. Écrire les relations qui en découlent. 8 2955 TG PA 00

Exercice 2 Une pizzeria veut créer un site pour informatiser ses commandes. Une personne pourra passer commande en précisant les pizzas désirées. Les pizzas sont présentées sur le site avec un nom, une liste d’ingrédients et un prix qui varie suivant la taille (petite, moyenne, grande). Pour chaque pizza commandée il faudra préciser la taille (sachant qu’on peut commander plusieurs fois la même pizza à des tailles différentes), la quantité et la liste des suppléments éventuels (qui sont en fait des ingrédients). Si plusieurs pizzas de même type et de même taille sont commandées, les suppléments sont les mêmes. Pour pouvoir passer commande, une personne doit créer un compte, en laissant son nom, prénom, adresse, téléphone et adresse mail. Le paiement se fait en ligne ou à la livraison : il faut juste mémoriser si la commande est payée ou non. Pour chaque commande, il faut aussi mémoriser la date et l’heure de la commande ainsi qu’un booléen pour savoir si la commande est livrée ou non. Construire le SCD correspondant. Écrire les relations qui en découlent.

Incidences de ces extensions Les sous-types sur association ont une incidence similaire aux sous-types sur entité : ils modifient la structure des données, donc la base de données. Les agrégations et les liens identifiants optimisent les liens entre les données : ils ont donc une incidence sur la gestion des clés étrangères. Les contraintes ont une incidence au niveau des traitements : elles se traduiront soit directement dans le code de l’application, soit plus classiquement dans le code de la base de données, sous forme de triggers ou de procédures stockées (abordés plus loin dans ce cours). Voici de façon plus détaillée les 4 extensions : les liens identifiants, les agrégations, les sous-types sur associations et surtout les contraintes.

Séquence 3 Extensions sous Merise/2

Page 73

2. Les sous-types sur association Rappelez-vous que le principe du sous-type (ou héritage) est d’éviter les attributs qui peuvent rester vides dans certains cas. Les sous-types sur association respectent les mêmes règles. Voyons un exemple. Vous voulez mémoriser le planning de réservation d’un gymnase. A priori, vous devriez obtenir dans un premier temps, ceci : GYMNASE idGymnase nom adresse

HORAIRE 1,n

PLANNING durée

0,n

date_heure

Petite remarque : l’identifiant de HORAIRE est volontairement date_heure, ce qui ne signifie pas qu’il y a plusieurs attributs mais un seul qui donne la date et aussi l’heure précise. Dans les SGBDR, vous avez toujours un type DateTime qui permet d’avoir en une fois la date et l’heure. Maintenant, compliquons le sujet : le gymnase peut être réservé soit pour des manifestations sportives (il faut alors connaître le titre de la manifestation et l’organisateur), soit pour des entraînements (il faut alors juste connaître le sport pour préparer le matériel nécessaire).

8 2955 TG PA 00

Sans sous-type, on serait obligé de faire comme ceci : GYMNASE

1,n

idGymnase nom adresse

PLANNING

HORAIRE

0,n

date_heure

durée titre 0,1

0,1

ORGANISATEUR 0,n

idOrganisateur nom adresse

SPORT 0,n

idSport nom

Avec cette représentation, l’attribut titre restera vide dans certains cas. Même problème pour les clés étrangères (d’où les cardinalités 0,1). Pour éviter ces attributs vides, il est possible de gérer des sous-types sur association : GYMNASE

1,n

idGymnase nom adresse

durée

MANIFESTATION

Séquence 3

PLANNING

0,n

HORAIRE date_heure

ENTRAINEMENT

titre

Extensions sous Merise/2

1,1

ORGANISATEUR

Page 74

idOrganisateur nom adresse

0,n

1,1

SPORT 0,n

idSport nom

Les sous-types sur association restent exceptionnels car, très souvent, l’association d’origine peut se transformer en entité. Par exemple, ici, il est possible d’éliminer HORAIRE par un lien identifiant.

Exercice 3 Dans un magasin spécialisé dans la vente d’ordinateurs, les clients peuvent passer commande pour plusieurs produits. La date de la commande doit être mémorisée. Pour chaque produit vendu dans une commande, il faut mémoriser la durée de garantie prise par le client. Compte tenu de la spécificité des produits, il n’y a pas de quantité à enregistrer (le produit est à chaque fois vendu en un seul exemplaire). Le client peut décider, pour certains produits, de prendre un contrat supplémentaire. Il existe plusieurs types de contrats (installation à domicile, pack formation, pack dépannage...). Donc, dans le cas où le client prend un produit avec un contrat, il faut mémoriser le type de contrat, la date d’effet, la durée, le montant (qui souvent est négocié). Construire le SCD correspondant. Écrire les relations qui en découlent.

8 2955 TG PA 00

3. Les contraintes Les contraintes représentent l’ajout le plus important dans les extensions Merise. Vous ne les avez pas du tout abordées dans le cours précédent.

Introduction Les contraintes permettent d’apporter des informations complémentaires sur les liens et dépendances entre les objets. Jusque là, elles étaient occultées ou, au mieux, précisées textuellement, à côté du MCD. Merise/2 permet maintenant de les intégrer de façon symbolique directement dans le schéma. Ces contraintes n’ont aucune incidence sur le modèle relationnel. C’est au niveau de la programmation qu’elles interviennent : soit directement dans le code, soit sous forme de triggers dans la base de données. La notion de trigger est abordée plus loin dans ce cours.

Couverture/disjonction Plusieurs contraintes sont basées sur la combinaison de 2 notions fondamentales : la couverture et la disjonction. Couverture : chaque tuple se trouve dans au moins un objet. objet 1 objet 2

Séquence 3 Extensions sous Merise/2

Page 75

Exemple : il existe des stages qui portent sur une matière, d’autres stages qui sont spécifiques à la préparation d’un examen, et enfin des stages qui ont les 2 vocations, mais il n’existe pas d’autres catégories de stage. Il y a aussi couverture même si aucun tuple n’est en commun. L’important est que tous les tuples soient dans les objets, aucun à l’extérieur. C’est donc la partie blanche du dessin ci-dessus qui est formellement interdite. Disjonction : chaque tuple se trouve dans au plus un objet.

objet 1

objet 2

8 2955 TG PA 00

Exemple : Un personnel peut être enseignant ou administratif, pas les 2 à la fois mais éventuellement il peut être d’une autre catégorie (par exemple personnel d’entretien). Il y a aussi exclusion quand tous les tuples sont dans les objets. L’important est qu’il n’y ait aucun tuple en commun entre les objets. C’est donc encore une fois la partie blanche du dessin ci-dessus qui est formellement interdite.

Exclusion La contrainte d’exclusion respecte la règle suivante : Chaque identifiant se trouve dans au plus un objet (disjonction) et certains tuples ne font partie d’aucun objet (non couverture). exclusion = non(couverture) + disjonction Exclusion sur héritage L’exclusion peut se faire entre plusieurs sous-types. Reprenons l’exemple précédent sur les sous-types des personnels. Le personnel se décompose en plusieurs catégories : les professeurs (dont on veut mémoriser le nombre d’heures et les matières enseignées), les administratifs (dont on veut mémoriser la date d’affectation et le service concerné). Il existe d’autres catégories de personnels pour lesquelles il n’y a pas d’informations spécifiques (juste les informations basiques : nom, prénom, adresse, téléphone et email). Séquence 3

PERSONNEL

Extensions sous Merise/2

idPersonnel nom prenom adresse tel email

Page 76

x ADMINISTRATIF

PROFESSEUR

dateAffectation

nbHeures

1,1 0,n

1,n

MATIERE_PROF

0,n

MATIERE idMatiere nom

SERVICE idService nom

La contrainte d’exclusion est représentée par une croix ("X") dans un losange (ou dans un rond) avec des branches pour s’accrocher aux liens d’héritage. Il y a autant de branches que de liens d’héritage concernés.

8 2955 TG PA 00

l ne peut pas y avoir de contrainte sur un héritage si l’héritage ne comporte qu’un O Isous-type. En revanche, à partir de 2 sous-types, la contrainte devient obligatoire (sauf si aucune contrainte ne correspond, ce qui est très rare). Exclusion sur association Il est possible aussi de trouver une contrainte d’exclusion entre 2 associations.  n enseignant peut participer à des stages. Il peut aussi être formateur de certains stages. U Mais pour un même stage, il ne peut pas être à la fois stagiaire et formateur. Certains enseignants ne sont ni stagiaire, ni formateur pour certains stages. FORMATEUR 0,n

0,n ENSEIGNANT idEnseignant nom tel

STAGE

x 0,n

0,n

idStage titre durée

STAGIAIRE

La contrainte se traduit ainsi : "Un couple idEnseignant+idStage ne peut pas être à la fois présent dans STAGIAIRE et dans FORMATEUR. Il peut aussi n’être présent dans aucun des 2."

Séquence 3 Extensions sous Merise/2

Exercice 4

Page 77

Un restaurant propose sur sa carte différents produits : des boissons, des plats et des menus. Tous les produits ont un nom et un prix. Les plats possèdent une liste d’ingrédients précisés sur la carte et sont classés dans une catégorie (entrée, plat, dessert). Les menus précisent une liste de plats proposés. Certains menus sont réservés au repas du midi : il n’est donc pas possible de les commander le soir. Construire le SCD correspondant. Écrire les relations qui en découlent.

Pivot À cette notion de contrainte sur association, se rajoute une notion supplémentaire appelée "pivot". Un pivot permet de dire quel identifiant est concerné par la contrainte. Pour mieux comprendre, reprenons la traduction donnée pour la contrainte précédente : "Un couple idEnseignant/idStage ne peut pas être à la fois présent dans STAGIAIRE et dans FORMATEUR. Il peut aussi n’être présent dans aucun des 2." Il est clairement dit que les identifiants concernés sont idEnseignant et idStage. Pour représenter cette implication des 2 identifiants, on la symbolise par des pointillés qui représentent donc les pivots de la contrainte :

8 2955 TG PA 00

FORMATEUR 0,n

0,n

ENSEIGNANT idEnseignant nom tel

STAGE

x 0,n

0,n

idStage titre durée

STAGIAIRE

Voici la phrase type pour lire une contrainte avec pivot : Il y a entre sur . Dans l’exemple précédent, cela donne : Il y a exclusion entre FORMATEUR et STAGIAIRE sur idEnseignant+idStage. orsque les pivots concernent toutes les entités sur lesquelles portent les associaO Ltions de la contrainte, alors ils sont optionnels. Donc la représentation précédente est équivalente à la représentation sans pointillés. Pour mieux comprendre l’importance des pivots, voyons justement d’autres possibilités sur le même exemple. Séquence 3

Voici une première possibilité : FORMATEUR

Extensions sous Merise/2

0,n

0,n

ENSEIGNANT Page 78

idEnseignant nom tel

STAGE

x 0,n

0,n

idStage titre durée

STAGIAIRE

Que signifie cette version ? En appliquant la règle vue précédemment sur le pivot, cela donne : Il y a exclusion entre FORMATEUR et STAGIAIRE sur idStage. Donc, si un idStage est présent dans FORMATEUR, il ne peut pas être présent dans STAGIAIRE, et vice versa. Donc, si un idEnseignant est présent dans FORMATEUR, il ne peut pas être présent dans STAGIAIRE, et vice versa. En français, cela donne : "Si un enseignant est formateur une fois, il ne pourra plus jamais être stagiaire, et vice versa.". Bien sûr, là encore ce n’est pas logique, mais si le pivot était ainsi positionné, cela se traduirait par cette contrainte.

8 2955 TG PA 00

Voici une seconde possibilité :

FORMATEUR 0,n

0,n

ENSEIGNANT idEnseignant nom tel

STAGE

x 0,n

0,n

idStage titre durée

STAGIAIRE

Que signifie cette version ? Il y a exclusion entre FORMATEUR et STAGIAIRE sur idEnseignant. Donc, si un idEnseignant est présent dans FORMATEUR, il ne peut pas être présent dans STAGIAIRE, et vice versa. En français, cela donne : "Si un enseignant est formateur une fois, il ne pourra plus jamais être stagiaire, et vice versa.". Bien sûr, là encore ce n'est pas logique, mais si le pivot était ainsi positionné, cela se traduirait par cette contrainte. Vous comprenez donc l’importance du pivot qui change complètement le sens de la contrainte. Avec l’exemple précédent, vous vous dites peut-être que, comme ça n’a pas de sens de mettre un seul pivot, autant les mettre tous (ou aucun). Attention, ce n’est pas parce que, dans cet exemple, un seul pivot n’est pas logique, que ça ne peut pas l’être dans d’autres cas. Voici un exemple : Une facture peut générer des avoirs qui seront alors reportés sur d’autres factures. Une facture qui génère un avoir ne peut en même temps comptabiliser des avoirs. 0,n

Séquence 3 Extensions sous Merise/2

Page 79

1,1

FACTURE

AVOIR

x

idFacture date 0,n

idAvoir montant 0,n

AFFECTATION

Cet exemple est aussi là pour rappeler qu’une CIF est une association, donc elle peut aussi porter une contrainte. uels que soient les pivots sélectionnés, faites attention qu’ils fassent FORCÉMENT O Qpartie des identifiants des deux associations concernées par la contrainte.

8 2955 TG PA 00

Exercice 5 Suivant le type de pathologie, certains médicaments sont conseillés, d’autres sont totalement proscrits. Pour chaque médicament conseillé, il faudra mémoriser la posologie. Construire le SCD correspondant. Écrire les relations qui en découlent.

Partition La contrainte de partition respecte la règle suivante : Chaque identifiant se trouve dans au plus un objet (disjonction) et aussi au moins un objet (couverture). partition = couverture + disjonction Partition sur héritage La partition peut se faire entre plusieurs sous-types. Exemple : Un message est soit urgent, soit normal, il ne peut bien sûr pas être les 2 et il ne peut pas être autre chose. Un nombre de rappels automatiques est programmé pour les messages urgents. Les messages normaux sont classés dans des catégories (rv, information, technique...). MESSAGE

Séquence 3

idMessage date heure titre contenu

Extensions sous Merise/2

Page 80

+ URGENT nb_rappels

NORMAL

1,1

0,n

CATEGORIE idCategorie nom

La contrainte de partition est représentée par un "+" ou par "XT" (qui signifie exclusion et totalité à la fois : vous verrez la contrainte de totalité juste après celle-ci). Partition sur association Il est possible aussi de trouver une contrainte de partition entre 2 associations : "Des analyses sont régulièrement faites sur les eaux directement récupérées en rivière (captage) et les eaux stockées dans des réservoirs. Une analyse porte soit sur un captage, soit sur un réservoir et obligatoirement sur l’un des deux."

8 2955 TG PA 00

0,n ANALYSE idAnalyse date résultat

0,1

CAPTAGE idCaptage débit

+ 0,1

RESERVOIR 0,n

idReservoir capacité

La contrainte se traduit ainsi : "idAnalyse ne peut pas être à la fois présent dans l’une et l’autre CIF. Il est forcément présent dans l’une des 2." Comme ce sont des CIF, elles se traduisent par des clés étrangères dans ANALYSE : il y aura donc 2 clés étrangères : une en relation avec CAPTAGE et l’autre en relation avec RESERVOIR. Cette contrainte traduit donc le fait qu’il y aura, pour chaque analyse, forcément une des 2 clés étrangères remplie (couverture) mais certainement pas les 2 à la fois (disjonction). Dans cet exemple, il n’y a pas d’ambiguïté possible sur le pivot : le seul pivot possible (commun aux 2 associations) est forcément idAnalyse. Il est donc inutile de le représenter : c’est le pivot par défaut. Cependant, ce n’est pas faux de le représenter : 0,n

idCaptage débit

0,1 ANALYSE idAnalyse date résultat

Séquence 3

CAPTAGE

Extensions sous Merise/2

+

Page 81

0,1

RESERVOIR 0,n

idReservoir capacité

Remarque Ce cas de figure aurait très bien pu être géré par un héritage : deux entités filles, analyse sur captage et analyse sur réservoir. Du coup, on aurait alors géré de simples CIF (avec cardinalités 1,1) partant de chacune des filles. La solution sans héritage est, dans ce cas, moins lourde car elle évite la création de 2 tables supplémentaires. Chaque type d’analyse ne portant pas d’informations spécifiques, excepté les 2 CIF, cela aurait été dommage de créer des tables supplémentaires. De manière plus générale, face à un héritage, il faut se poser la question de la solution la plus adaptée. Parfois les 2 solutions sont tout à fait défendables.

Exercice 6 Une agence de location de véhicules propose 3 types de véhicules : les véhicules légers, les utilitaires, les camions. Pour les véhicules légers, le modèle et la marque sont renseignés, ainsi que le nombre de CV. Pour les utilitaires, la capacité en mètres cubes est précisée. Enfin, pour les camions, le tonnage et la hauteur sont donnés. Pour chaque type de véhicule, une photo est proposée. Construire le SCD correspondant. Écrire les relations qui en découlent.

8 2955 TG PA 00

Totalité La contrainte de totalité respecte la règle suivante : Chaque identifiant se trouve dans au moins un objet (couverture) et certains tuples peuvent faire partie de plusieurs objets à la fois (non disjonction). totalité = couverture + non(disjonction) Totalité sur héritage La totalité peut se faire entre plusieurs sous-types. Exemple : Certains stages sont spécifiques à la préparation d’un examen. Certains stages portent sur une matière précise. Un stage peut aussi avoir les 2 rôles. Il n’y a pas d’autres types de stages. STAGE idStage titre date nbPlaces

EXAMEN idExamen nom

idMatiere nom

T

0,n Séquence 3

MATIERE

1,1

0,n

STAGE EXAM

STAGE MATIERE

1,1

Extensions sous Merise/2

Page 82

La contrainte de totalité est représentée par un "T". Totalité sur association Il est possible aussi de trouver une contrainte de totalité entre 2 associations :

 n article est acheté auprès de fournisseurs ou fabriqué en ateliers. Il peut aussi être acheté U auprès de fournisseurs puis être transformé en ateliers. Il n’y a pas d’autres possibilités. ACHAT 0,n

0,n

ARTICLE idArticle nom prixVente

FOURNISSEUR idFournisseur nom adresse

T 0,n

ATELIER FABRICATION

0,n

idAtelier nom spécialité

La contrainte se traduit ainsi : "idArticle est forcément présent soit dans ACHAT, soit dans FABRICATION, soit dans les 2." Encore une fois, dans cet exemple, il n’y a pas d’ambiguïté sur le pivot : le seul pivot possible (commun aux 2 associations) est forcément idArticle. Sa représentation est donc optionnelle.

8 2955 TG PA 00

Exercice 7 Une grande entreprise organise des séminaires. Chaque séminaire se fait à une date précise. Il faut connaître aussi la durée (en nombre de jours) et le lieu. Un séminaire peut être composé de séances de travaux pratiques et aussi de conférences. Une conférence possède un titre. Il faut aussi connaître les conférenciers. Les travaux pratiques comportent un objectif détaillé, une durée et un formateur. Les conférences et les séances de travaux pratiques peuvent être intégrées dans plusieurs séminaires. Cependant les intervenants ne changent pas. On mémorise le nom et le téléphone de chaque intervenant. Un intervenant peut très bien intervenir au niveau des TP ou des conférences, ou même les deux. On enregistre les intervenants qu’à partir du moment où ils sont intervenus au moins une fois. Construire le SCD correspondant. Écrire les relations qui en découlent. À partir de maintenant, nous allons voir des contraintes qui n’utilisent plus les notions de couverture et de disjonction. Ces contraintes ne peuvent pas non plus être utilisées sur des héritages : elles ne portent que sur des associations.

Égalité ou simultanéité La contrainte d’égalité (ou de simultanéité) respecte la règle suivante : Si un identifiant (correspondant au pivot) est présent dans un objet, il est forcément présent dans l’autre, et vice versa. Exemple : Une personne qui pratique un sport fait partie d’une équipe, et vice versa. SPORT PERSONNE 0,n

0,n

PERSONNE idPersonne nom adresse

SPORT

Séquence 3 Extensions sous Merise/2

Page 83

idSport nom

= 0,n

EQUIPE EQUIPE PESONNE

0,n

idEquipe nom

La contrainte d’égalité (ou simultanéité) est représentée par un "=" (ou un "S"). La contrainte se traduit ainsi : "Si idPersonne est présent dans SPORT_PERSONNE, il est forcément présent dans EQUIPE_PERSONNE, et vice versa."

Exercice 8 Dans une université, un professeur est responsable d’au moins un cours dès qu’il a participé à au moins une publication. Plusieurs professeurs peuvent être responsables du même cours. Un cours a un nom et un niveau requis. Il faut mémoriser le titre et la date de chaque publication. Pour chaque professeur, il faut mémoriser son nom, son téléphone, son adresse email et savoir si c’est un chercheur. Construire le SCD correspondant. Écrire les relations qui en découlent.

8 2955 TG PA 00

Inclusion La contrainte d’inclusion respecte la règle suivante : Si un identifiant (correspondant au pivot) est présent dans un objet, il est forcément présent dans l’autre, mais pas forcément réciproquement. Cette fois, contrairement à l’égalité, il n’y a pas de réciprocité. Cette contrainte est très courante. Pour montrer le sens de la contrainte, et donc de l’inclusion, il faut ajouter une flèche. Exemple : Une personne inscrite à un stage a dù en faire la demande préalable. Toutes les demandes de stage ne sont pas forcément satisfaites. DEMANDE PERSONNE idPersonne nom tel

0,n

0,n

I 0,n

0,n

STAGE idStage titre durée

INSCRIPTION présence

O Attention à la flèche qui est obligatoire ! Séquence 3 Extensions sous Merise/2

Page 84

La contrainte d’inclusion est représentée par un "I". La contrainte se traduit ainsi : "Si le couple idPersonne+idStage est présent dans INSCRIPTION, il est forcément présent dans DEMANDE."

Exercice 9 Le rédacteur en chef d’un journal s’occupe de récupérer un ensemble d’articles candidats à la publication dans chaque rubrique du journal. Ce sont les auteurs des articles qui proposent leurs articles en précisant la ou les rubriques concernées. Donc un même article peut être candidat dans plusieurs rubriques. Le rédacteur en chef réunit alors un comité qui s’occupe de faire un tri et de choisir les articles qui leur paraissent les plus adaptés pour être publiés. Le comité donne aussi un classement de préférence pour les articles choisis par rubrique. Un même article peut être choisi dans plusieurs rubriques différentes. Au final, c’est le rédacteur en chef qui décide des articles publiés, parmi les articles choisis, sachant qu’un même article ne peut être publié que dans une rubrique. Pour chaque article, on mémorisera le titre, la date, le contenu et l’auteur. Construire le SCD correspondant. Écrire les relations qui en découlent.

Inclusion à portée multiple L’inclusion à portée multiple met en jeu au moins 3 associations. L’inclusion ne se fait toujours que dans une seule association. Cela traduit juste le fait que les pivots doivent parfois être récupérés dans des entités qui ne sont pas directement liées à l’association de départ.

8 2955 TG PA 00

Un exemple va certainement permettre de mieux comprendre le principe : Une personne peut conduire un véhicule que si elle possède le bon permis. CONDUIT

0,n

0,n

VEHICULE idVehicule immatriculation 1,1

PERSONNE

I

idPersonne nom adresse

0,n 0,n PERMIS PERSONNE

PERMIS 0,n

idPermis description

La contrainte se traduit ainsi : "Le couple idPersonne+idPermis formé en passant par CONDUIT et la CIF entre VEHICULE ET PERMIS, doit être présent dans PERMIS_PERSONNE." l faut que les liens directs qui forment la base de l’inclusion permettent d’accéder O Iaux pivots. La flèche reste unique. Séquence 3

Cette contrainte est assez courante : vous aurez l’occasion de la pratiquer dans plusieurs exercices issus des sujets d’examen.

Extensions sous Merise/2

Exercice 10

Page 85

Un stage porte sur un ensemble de compétences. Un formateur possède un ensemble de compétences. Plusieurs formateurs peuvent intervenir sur un même stage, à condition bien sûr qu’ils aient toutes les compétences requises. Construire le SCD correspondant. Écrire les relations qui en découlent.

Unicité La contrainte d’unicité est en fait une autre représentation de la CIF partant d’une association. Vous devez donc connaître les 2 représentations. Personnellement je préfère la CIF qui traduit à chaque fois une clé étrangère. La contrainte d’unicité est la seule contrainte qui a du coup une influence sur le modèle relationnel puisqu’elle se traduit, comme la CIF, par une clé étrangère. Exemple : Plusieurs personnels peuvent intervenir en qualité de formateur sur un stage. Pour chaque intervention, il faut connaître la durée en nombre d’heures et le type d’intervention (cours magistral, travaux dirigés, travaux pratiques ...).

8 2955 TG PA 00

Voici la représentation avec le CIF sur association :

0,n

FORMATEUR durée

0,n

1,1

STAGE idStage titre date

PERSONNEL 0,n

idPersonnel nom tel

TYPE INTERVENTION idIntervention libellé

Voici la représentation avec la contrainte d’unicité : FORMATEUR 0,n

durée

idStage titre date

0,n

1

PERSONNEL idPersonnel nom tel

TYPE INTERVENTION idIntervention libellé

Séquence 3 Extensions sous Merise/2

Page 86

STAGE

0,n

Attention, au niveau relationnel, FORMATEUR n’est pas une ternaire (association à 3 liens directs) : elle ne contient en réalité que 2 attributs en clé primaire et la contrainte d’unicité permet de récupérer la troisième clé en clé étrangère uniquement. Certains font même une représentation avec 2 associations. Cette représentation est encore plus lourde visuellement, sans compter le fait que la ternaire ne sera bien sûr pas du tout traduite par une relation : FORMATEUR 0,n PERSONNEL idPersonnel nom tel

durée

0,n

STAGE idStage titre date

1 0,n

0,n INTERV_FORMATEUR 0,n

TYPE INTERVENTION idIntervention libellé

8 2955 TG PA 00

Ces 3 représentations sont totalement équivalentes. Il existe encore d’autres variantes : certains mettent les branches de la contrainte directement sur les branches de l’association... L’idée est que vous soyez capable de vous adapter à plusieurs lectures.

Exercice 11 Dans chaque classe, chaque cours est enseigné par un seul professeur. Pour chaque classe, il faut connaître le volume horaire réservé pour chaque cours. Construire le SCD correspondant. Écrire les relations qui en découlent.

4. Exercices récapitulatifs Tous ces exercices sont issus de sujets officiels. Les schémas sont plus ou moins importants suivant les années, cependant ils contiennent forcément des notions de Merise/2. Le plus difficile est généralement de bien comprendre le sujet. Autre point primordial : vous avez, à travers cette séquence et la précédente, utilisé une méthode précise en ayant un rapide aperçu des variantes existantes. Le but était avant tout de vous apprendre à raisonner sur des sujets d’analyse. À travers ces sujets d’examen, vous allez être confronté à plusieurs variantes : vous avez normalement acquis le recul nécessaire pour vous adapter. Donc ne soyez pas surpris si vous voyez des cif présentées sous forme d’association avec un verbe à l’intérieur : seule la cardinalité vous permettra de repérer la cif. Quelle que soit la méthode présentée dans le sujet (qui apparaît parfois dans des extraits de MCD donnés dans le sujet), rappelez-vous que vous avez tout à fait le droit d’utiliser la variante de présentation de votre choix. Celle qui est la plus pratique pour vous et qui vous convient le mieux. Dans ce type de sujet, vous êtes souvent confronté à des annexes : pensez à les lire en détail ainsi que le sujet lui-même. Souvent les annexes contiennent des informations primordiales, par exemple vous pouvez découvrir à travers un tableau exemple que la numérotation est relative, donc qu’il faut faire un lien identifiant.

Séquence 3 Extensions sous Merise/2

Page 87

Dernière remarque avant de commencer : il arrive très souvent que les sujets officiels comportent des erreurs. Rares sont les fois où ces erreurs sont signalées en cours de composition (même si les professeurs voient l’erreur en lisant rapidement le sujet, il faut avoir l’autorisation de Paris pour avertir les étudiants). Du coup, vous devez être capable de vous en sortir tout seul. Mais ne vous inquiétez pas : faites simplement au mieux. Quand une erreur est repérée, la correction est alors forcément très généreuse.

8 2955 TG PA 00

Exercice 12 Extrait du Cas NOIXCOOP (métropole 2010) NOIXCOOP est une coopérative agricole spécialisée dans la collecte, la transformation et le conditionnement de la noix qualifiée "noix de Grenoble". Les membres de la coopérative sont des producteurs situés dans la vallée de l’Isère (affluent du Rhône). Documents à utiliser : annexes 1A et 1B. NOIXCOOP est engagée dans une démarche qualité et souhaite améliorer la traçabilité de ses produits. Elle envisage donc de réorganiser la partie de son système d’information relative à la gestion des approvisionnements et des ventes. Les producteurs Les membres de la coopérative sont des producteurs de noix, appelés nuticulteurs. Chaque année, la coopérative accepte, dans une certaine proportion, la production de producteurs non adhérents. Les producteurs qui sont engagés dans la lutte pour le respect de l’environnement obtiennent des certifications garantissant leur engagement dans ce domaine (par exemple les labels Agriculture Biologique et GLOBALGAP). Pour les producteurs adhérents, on conserve une trace des différentes certifications qu’ils possèdent (certification et date d’obtention). Séquence 3 Extensions sous Merise/2

Page 88

La coopérative souhaite conserver dans son système d’information certaines caractéristiques des producteurs avec lesquels elle travaille : nom et adresse de la société, nom et prénom du responsable de production. Pour les producteurs adhérents, il faut également conserver la date de leur adhésion. Les vergers Un producteur peut exploiter plusieurs vergers. Parmi les caractéristiques d’un verger, on trouve la variété de la noix, la superficie plantée et le nombre d’arbres à l’hectare. Certains vergers permettent au producteur d’obtenir les labels AOC (appellation d’origine contrôlée), avec l’appui du Comité Interprofessionnel de la Noix de Grenoble. Pour avoir droit à l’appellation d’origine contrôlée (AOC), les productions de noix doivent remplir deux conditions : –– provenir de vergers situés dans les communes référencées par la réglementation. Ces communes sont toutes situées le long de la vallée de l’Isère ; –– correspondre aux variétés de noix Franquette, Mayette ou Parisienne. La production Chaque année la coopérative réceptionne les récoltes de ses producteurs. Cette activité de l’entreprise, comme toutes les autres, doit être inscrite dans une démarche qualité assurant la traçabilité des produits finis. Afin d’assurer cette traçabilité, la coopérative identifie chaque livraison de noix réalisée par un producteur. Une livraison est caractérisée par le verger dont proviennent les noix, sa date, le type de produit (entière fraîche ou entière sèche) et la quantité livrée.

8 2955 TG PA 00

Après réception, les noix sont triées en fonction de leur taille (voir annexe 1A). La coopérative utilise pour cela une calibreuse destinée à répartir la livraison en différents lots de production. Un lot de production est donc constitué de l’ensemble des noix d’une livraison conformes à un calibre particulier. L’annexe 1B présente un exemple de livraison répartie en différents lots de production. Les campagnes de ventes Les noix sont vendues à des clients qui sont pour l’essentiel des grossistes, des entreprises de la grande distribution ou des professionnels des métiers de la bouche (pâtissiers, restaurateurs). Une commande est caractérisée par un numéro de commande, une date de commande et un client. Chaque commande porte sur un seul lot de production déterminé en fonction de la demande du client (variété de noix, type de produit et calibre), ce qui permet d’assurer la traçabilité des produits vendus. Les informations concernant le client (nom, adresse, nom du responsable des achats) doivent être enregistrées. Pour chaque commande, il faut également mémoriser les types de conditionnement et les quantités commandés. Les différents types de conditionnement proposés par NOIXCOOP sont : le sachet (de 250 g, 500 g et 1 kg), le filet (de 1 kg, 5 kg, 10 kg et 25 kg) et le carton de 10 kg. Une commande peut par exemple comporter 800 sachets de 1 kg et 300 filets de 10 kg pour un poids total de 3 800 kg. Séquence 3

Travail à faire 1. À partir des informations fournies dans ce dossier et des annexes 1A et 1B, établir un schéma entité association des données concernant les approvisionnements et les ventes de noix.

Extensions sous Merise/2

Page 89

Annexe 1A : Les calibres de noix Identifiant

libellé

1

inférieur à 24 mm

2

24 à 28 mm

3

28 à 30 mm

4

30 à 32 mm

5

32 à 34 mm

6

supérieur à 34 mm

8 2955 TG PA 00

Annexe 1B : Exemple de livraison Code Livraison : L0512

Date de livraison : 18/04/2010

Producteur : Verger : Les noix de Polienas

V058 - Verger du moulin

52, route de Grenoble 38 210 POLIENAS Variété : Franquette

Quantité : 12 520 Kg

Type de produit : Entière fraîche Lots de production après calibrage : Numéro de lot

Calibre

Quantité

1

24 à 28 mm

4 200 Kg

2

28 à 30 mm

3 820 Kg

3

30 à 32 mm

1 580 Kg

4

32 à 34 mm

2 920 Kg

Séquence 3 Extensions sous Merise/2

Page 90

Exercice 13 Extrait du Cas SEG (métropole 2009) L’eau potable a toujours été l’un des premiers objets de coopération intercommunale. La sécurité de l’alimentation face à une ressource rare, difficile à mobiliser ou de mauvaise qualité, a poussé les municipalités à regrouper leurs moyens pour obtenir une distribution de qualité. Le Syndicat des Eaux de Gévaudan (SEG) s’est ainsi donné pour mission le captage, le traitement et la distribution de l’eau potable pour satisfaire les usagers répartis sur le territoire des communes regroupées au sein d’un syndicat de communes. Le service public d’eau est géré en régie : son organisation et son fonctionnement sont assurés directement par le syndicat de communes, qui conserve ainsi une maîtrise complète de sa gestion avec ses propres moyens matériels, humains et financiers. Les communes ont la responsabilité complète des investissements, du fonctionnement des services des eaux, des relations avec les usagers, comme l’émission des factures d’eau et leur recouvrement. À utiliser : annexe 1 L’article 73 de la Loi Barnier du 2 février 1995, relative à la protection de l’environnement, précise que le maire ou le président d’un syndicat de communes doit présenter à son assemblée délibérante un rapport annuel sur le prix et la qualité des services publics de l’eau potable et de l’assainissement. La rédaction de ce rapport repose sur une parfaite connaissance du réseau de production d’eau potable.

8 2955 TG PA 00

Le captage et le traitement de l’eau sont des activités qui consistent à recueillir l’eau et à la traiter pour la rendre potable. Environ la moitié de l’eau distribuée par le SEG provient des eaux de surface (rivières, lacs, fleuves) prélevées par un simple pompage. L’autre moitié provient des eaux souterraines qui s’accumulent dans des réservoirs naturels. Il s’agit de cavités retenant l’eau entre deux couches géologiques imperméables. Le captage de ces eaux souterraines s’effectue par l’intermédiaire d’un forage pouvant atteindre 700 m de profondeur. Les eaux souterraines sont en général de meilleure qualité car elles sont davantage protégées de la pollution du fait de leur éloignement de la surface. Chaque captage (pompage ou forage) géré par le SEG est caractérisé par un code, un nom et un débit maximal exprimé en m3 d’eau capté par heure d’exploitation. S’il s’agit d’un pompage, il est nécessaire de connaître la nature de la réserve d’eau exploitée (rivière, lac ou fleuve). Pour les forages, les données importantes à retenir sont la profondeur et le diamètre. Le débit effectif d’un captage dépend évidemment de la pluviométrie. Pour chaque captage, on retient le débit moyen observé en fonction du mois de l’année, ce qui permet de prévoir les éventuels problèmes d’alimentation en eau. Chaque captage sert à l’alimentation de plusieurs réservoirs dont la fonction est le stockage de l’eau à distribuer. Un réservoir a une capacité maximale, il est soit enterré, soit aérien (château d’eau). Un réservoir enterré est muni d’un groupe de surpression permettant d’envoyer l’eau sous pression dans les canalisations servant à la distribution. Ce groupe de surpression est caractérisé par son débit maximal en m3 par seconde. Un château d’eau ne nécessite pas de groupe de surpression car il est construit sur une hauteur, ce qui permet à l’eau de s’écouler naturellement dans les canalisations de distribution. Des pompes permettent d’alimenter le château d’eau. Elles se mettent automatiquement en service lorsque l’eau atteint la hauteur minimale prévue et s’arrêtent lorsqu’elle atteint la hauteur maximale prévue pour le château d’eau. Outre les hauteurs minimale et maximale, il est important de connaître le temps nécessaire au remplissage d’un château d’eau et la pression de l’eau obtenue en sortie au pied de l’édifice.

Séquence 3 Extensions sous Merise/2

Page 91

L’annexe 1 présente un extrait de la liste des réservoirs gérés par le SEG. Pour garantir la continuité de service de distribution d’eau potable, chaque réservoir est donc relié à un ou plusieurs captages de secours pour le cas où le captage principal devait être interrompu. La mise en service de la connexion d’un réservoir à l’un de ses captages de secours est sous la responsabilité d’un technicien, dont il faut connaître le matricule, le nom, le prénom et le numéro de téléphone mobile. La production d’eau est soumise à des normes de qualité très exigeantes. Pour respecter ces normes, l’eau brute doit passer par des traitements sophistiqués. Le SEG effectue fréquemment des analyses de l’eau en collaboration avec un laboratoire indépendant. Ces analyses sont réalisées d’une part au niveau des captages, d’autre part au niveau des réservoirs. Elles permettent de vérifier que l’eau respecte bien les critères de qualité des eaux destinées à la consommation humaine.

8 2955 TG PA 00

Deux critères de qualité biologiques sont impératifs : on ne tolère la présence d’aucune bactérie de type "Escherichia Coli" ni d’aucun entérocoque dans l’eau. En ce qui concerne les substances chimiques et les métaux (arsenic, cadmium, cyanure, mercure, plomb, etc.), la réglementation fixe pour chacun d’entre eux une concentration maximale à ne pas dépasser exprimée en µg par litre. Il est nécessaire de mémoriser les résultats obtenus à chaque analyse.

Travail à faire 1. Proposer un schéma entité-association représentant les besoins informationnels pour la gestion du réseau de production d’eau potable. La distribution de l’eau aux clients se fait par l’intermédiaire d’abonnements. Un client souscrit un abonnement pour chacun de ses logements (résidence principale ou secondaire). Pour chaque abonnement, la quantité d’eau consommée est mesurée à l’aide d’un compteur d’eau. Il arrive que le SEG soit amené à changer le compteur d’eau d’un abonnement (compteur défaillant par exemple). Un seul compteur est en service à un instant donné pour chaque abonnement mais on conserve l’historique de tous les compteurs d’un abonnement. Un compteur est repéré par la référence de l’abonnement et un numéro séquentiel correspondant à son ordre d’installation (le premier compteur d’un abonnement porte le numéro 1, le second le numéro 2, ...). Séquence 3

Périodiquement, les agents du SEG procèdent au relevé de chaque compteur d’eau en service afin de préparer le travail de facturation.

Extensions sous Merise/2

Pour gérer l’ensemble de ces informations, le SEG dispose de la base de données de schéma :

Page 92

CLIENT(id, nom, prenom, adresse, cp, ville) id : Clé primaire ABONNEMENT(ref, date, client, adresse, cp, ville) ref : Clé primaire client : Clé étrangère en référence à id de CLIENT COMPTEUR(abonnement, numOrdreCompteur, dateInstallation, marque)  abonnement, numOrdreCompteur : Clé primaire abonnement : Clé étrangère en référence à ref de ABONNEMENT RELEVE(abonnement, numOrdreCompteur, numOrdreReleve, date, index) La clé primaire et les clés étrangères ne sont pas indiquées ici.

Chaque relevé est identifié par l’identifiant du compteur concerné et un numéro séquentiel. L’attribut index de la table RELEVE indique le nombre de m3 d’eau mesuré par le compteur à la date du relevé (consommation réalisée depuis la mise en service du compteur). Il convient de remarquer que lors de l’installation d’un nouveau compteur, l’index du compteur est initialisé à zéro.

Travail à faire 2. Présenter le schéma entité-association correspondant au schéma relationnel de la base de données utilisée.

8 2955 TG PA 00

Annexe 1 : Extrait de la liste des réservoirs Réservoir : R01, dôme du loup Type : château d’eau Captage principal : C05, forage du bois des pins Captages de secours : Captage

Remarques en cas de recours au captage de secours Technicien responsable

C08

Ne pas déclencher la procédure d’urgence

T07, Laurent Boissé

C13

Activer le relai de pompage

T15, Danièle Pivert

Réservoir : R02, Sauges en Gévaudan Type : réservoir enterré Captage principal : C09, lac de la forge Captages de secours : Captage

Remarques en cas de recours au captage de secours Technicien responsable

C08

Prévenir le centre de contrôle

T15, Danièle Pivert

C14

Diminuer le débit d’un tiers

T15, Danièle Pivert

Réservoir : R03, la ferme aux loutres Type : réservoir enterré Captage principal : C05, forage du bois des pins

Séquence 3

Captages de secours :

Extensions sous Merise/2

Captage

Remarques en cas de recours au captage de secours Technicien responsable

C19

Enclencher la double alimentation

T07, Laurent Boissé

C23

Baisser le groupe de surpression

T16, Mehdi Yayaoui

C13

Ne pas activer le relai de pompage

T16, Mehdi Yayaoui

Page 93

Exercice 14 Extrait du Cas ERGOSUM (nouméa 2009) La société de services informatiques ERGOSUM propose des développements informatiques sur mesure à une clientèle d’entreprises ou d’organisations n’ayant pas trouvé de solutions satisfaisantes dans les progiciels standards du marché. La société ERGOSUM vient d’être saisie d’une demande du comité d’établissement (CE) d’une entreprise régionale. Celui-ci souhaite améliorer sa gestion en accroissant l’automatisation du traitement de ses activités. Il propose un large éventail de prestations concernant les loisirs et activités extraprofessionnelles des employés et de leurs familles. Les différents types de prestations proposées vont du prêt de livres à la vente de billets de cinéma à tarif réduit, en passant par la proposition de séjours de vacances et la vente de jouets à l’occasion des fêtes de fin d’année. M. Latin, responsable du CE, est l’interlocuteur d’ERGOSUM dans l’entreprise.

8 2955 TG PA 00

Annexes à utiliser : 1, 2a, 2b Sur le site intranet, il est actuellement possible de visualiser les bulletins d’inscription au format PDF et de les imprimer (annexes 2a et 2b). Une fois complétés, ces bulletins d’inscription sont envoyés par courrier au CE pour traitement. L’objectif de M. Latin est de mettre en ligne sur l’intranet une application permettant aux salariés de l’entreprise d’enregistrer directement leurs réservations de séjours. Il faut donc compléter l’actuelle base de données (annexe 1). Précisions concernant les séjours • Chaque séjour est destiné à une tranche d’âge (code, âge minimum et âge maximum). • Chaque séjour thématique propose aux participants un certain nombre d’activités. • Chaque séjour linguistique peut comprendre des excursions. Il propose dans tous les cas un perfectionnement en langue qui peut prendre une des formes suivantes : cours particuliers, stage intensif, préparation examen… Modalités d’inscription d’un enfant L’inscription d’un enfant à un séjour se fait par l’intermédiaire d’une demande d’inscription (annexes 2a et 2b). On souhaite conserver l’historique des demandes pour l’année en cours. En début d’année, le catalogue des séjours est actualisé (dates et prix des séjours), les demandes de l’année écoulée sont supprimées. Séquence 3 Extensions sous Merise/2

Page 94

L’état d’une demande doit être enregistré : à traiter, en cours, satisfaite, non satisfaite. > Demande d’inscription pour un séjour thématique Pour chaque demande concernant un séjour thématique, il est possible de retenir jusqu’à trois séjours, numérotés de 1 à 3, par ordre de préférence. Dans le cas où le premier séjour est complet, on passe au second, dans le cas où le second est complet, au troisième. Le séjour retenu (parmi les trois choix possibles) doit être mémorisé lorsque la demande est satisfaite. L’enfant doit choisir l’activité qu’il souhaite pratiquer parmi les activités proposées pour chaque séjour. > Demande d’inscription pour un séjour linguistique Dans ce type de demande, on ne peut choisir qu’un seul séjour.

Travail à faire 1. P  résenter le schéma entité-association permettant de représenter le catalogue de séjours ainsi que la gestion des demandes de séjour en vous appuyant sur le schéma relationnel présenté en annexe 1 et les besoins exprimés par M. Latin. 2. R  eprésenter en complétant votre schéma la règle de gestion suivante  : "toute demande concerne un ou plusieurs séjours thématiques ou (exclusif) un séjour linguistique".

8 2955 TG PA 00

Annexe 1 : Extrait du schéma relationnel Lieu (id, libellé, pays) Clé primaire : id Séjour (ref, résumé, dateDébut, dateFin, prix, type, idLieu) Clé primaire : ref Clé étrangère : idLieu en référence à id de Lieu Remarque : l’attribut type est de type caractère et contient ‘T’ pour un séjour thématique et ‘L’ pour un séjour linguistique. VilleDépart (id, nom) Clé primaire : id Partir (refSéjour, idVille, supplément) Clé primaire : refSéjour, idVille Clé étrangère : refSéjour en référence à ref de Séjour Clé étrangère : idVille en référence à id de VilleDépart Excursion (refSéjour, num, objet, idLieu) Clé primaire : refSéjour, num Clé étrangère : refSéjour en référence à ref de Séjour Clé étrangère : idLieu en référence à id de Lieu

Remarques Les départs de chaque séjour proposé s’effectuent de Paris ou d’autres grandes villes. Dans le cas d’un départ d’une ville autre que Paris, une majoration est appliquée, déterminée en fonction du séjour et de la ville de départ. Il existe deux types de séjours : • les séjours thématiques ; • les séjours linguistiques : l’objectif est de permettre à l’enfant de se perfectionner dans la langue de son choix. Ces séjours se déroulent à l’étranger dans une famille d’accueil et peuvent comprendre des excursions. Le schéma conceptuel réalisé pour produire ce schéma relationnel présentait deux entités spécialisées "séjour thématique" et "séjour linguistique".

Séquence 3 Extensions sous Merise/2

Page 95

Annexe 2a : Exemple de bulletin d’inscription pour un séjour thématique DEMANDE D’INSCRIPTION SÉJOUR THÉMATIQUE - ANNÉE 2009 Renseignements sur le salarié Matricule : 3582 Nom : MARTIN Prénom : Paul Adresse : 12, rue des Platanes Code postal : 42000

Ville : Saint Étienne

Tél fixe : 04.50.98.12.56 Mél : [email protected] Renseignements sur l’Enfant Nom : MARTIN Prénom : Stéphane Date de naissance : 23/09/1997 Sexe : M þ F ¨ Ville de départ choisie : Lyon

8 2955 TG PA 00

Séjours thématiques demandés (par ordre de préférence) : Référence

Lieu

Activité retenue

Dates

1

E1090071

La Plagb-ne

Escalade

Du 12/07 au 26/07

2

E1090134

Pralognan

Parapente

Du 10/07 au 25/07

3 NE RIEN INSCRIRE DANS CE CADRE - RÉSERVÉ AU CE Référence demande : Date demande : Demande retenue : 1 ¨ 2 ¨ 3 ¨ Aucune o Annexe 2b : Exemple de bulletin d’inscription pour un séjour linguistique DEMANDE D’INSCRIPTION SÉJOUR LINGUISTIQUE - ANNÉE 2009 Renseignements sur le salarié Matricule : 3582 Nom : MARTIN Prénom : Paul Séquence 3 Extensions sous Merise/2

Page 96

Adresse : 12, rue des Platanes Code postal : 49000

Ville : Saint Etienne

Tél fixe : 04.50.98.12.56 Mél : [email protected] Renseignements sur l’Enfant Nom : MARTIN Prénom : Julie Date de naissance : 14/11/1990 Sexe : M ¨ F þ Ville de départ choisie : Lyon Séjour linguistique demandé : Référence E6061713

Lieu Colorado

Dates Du 10/07 au 31/07

NE RIEN INSCRIRE DANS CE CADRE - RÉSERVÉ AU CE Référence demande : Date demande : Demande retenue : oui ¨ non ¨

8 2955 TG PA 00

Exercice 15 Extrait du Cas CAPDC (métropole 2008) La chambre d’agriculture du Pas-de-Calais (CAPDC) assure des missions d’accompagnement pour le développement de l’agriculture dans son département. Elle propose aux agriculteurs des prestations diverses : • analyses de projets d’installation, de diversification... ; • actions de sensibilisation et de promotion autour des métiers de l’agriculture ; • formation et conseils sur la prise en compte de préoccupations environnementales (gestion des milieux naturels, élimination des déchets...). Au titre de la protection des milieux naturels, les agriculteurs sont tenus de rendre compte des quantités d’engrais et de traitements (pesticides, désherbants...) apportés à leurs cultures. Ce contrôle conditionne les aides accordées aux agriculteurs dans le cadre de la politique agricole commune (PAC). Les agriculteurs doivent donc remplir régulièrement un cahier d’épandage pour les engrais et un registre phytosanitaire pour les traitements. Le service informatique de la Chambre d’Agriculture a sollicité la SSII Sigeto pour collaborer au projet AIM (Agriculture Information Maîtrisée) dont l’objectif est de faciliter la gestion des échanges entre les agriculteurs et les autres acteurs du monde agricole. Le logiciel AIM permettra de saisir, stocker, consulter et échanger des données relatives à l’exploitation agricole et aux activités de culture et d’élevage. Il constituera une aide à la déclaration, à la traçabilité et à la gestion technico-économique de l’exploitation. Annexe à utiliser : 1 Le système d’information à concevoir mémorisera les données concernant l’épandage de produits fertilisants azotés apportés aux cultures des exploitations agricoles du département sur plusieurs années culturales. Chaque année culturale débute le 1er juillet de l’année n et se termine le 30 juin de l’année n+1.

Séquence 3 Extensions sous Merise/2

Page 97

Chaque exploitation est composée de plusieurs îlots. Un îlot est un regroupement de parcelles contiguës, limité par des éléments facilement repérables et permanents (comme un chemin, une route, un ruisseau…) et stable d’une année culturale sur l’autre. Le découpage d’un îlot en parcelles est variable d’une année culturale à l’autre, en fonction des mises en cultures envisagées. Exemple : Découpage d’un îlot

8 2955 TG PA 00

Pour une exploitation, on mémorise un code exploitation et les coordonnées de l’exploitant. La collecte des informations pour une exploitation donnée s’effectuait jusqu’à présent sur un document papier appelé cahier d’épandage (cf. annexe 1). Dans ce cahier d’épandage sont notées, pour chaque parcelle cultivée : • la surface en hectares (ha) ; • l’espèce cultivée (blé, orge, betteraves...) caractérisée par un code et un libellé ainsi que les rendements prévus et ceux réalisés ; • les informations concernant les apports en produits azotés. Pour chaque produit azoté, on indique notamment la quantité d’azote apportée par hectare et la date de l’apport. Les produits azotés peuvent être de nature minérale (engrais minéraux de synthèse) ou de nature organique (déjection animale, boues de station d’épuration, compost...). Un produit minéral a une teneur en azote qui lui est propre ; • l’apport de produits de nature organique donne lieu à l’enregistrement d’informations supplémentaires : –– l’origine, –– le délai d’enfouissement, –– la présence d’un traitement anti-odeur, –– la teneur en azote mesurée. Séquence 3 Extensions sous Merise/2

Page 98

8 2955 TG PA 00

Travail à faire  roposer un schéma entité-association représentant les informations nécessaires P à l’informatisation de la collecte et du traitement des cahiers d’épandage des exploitations agricoles du département sur plusieurs années.

Séquence 3 Extensions sous Merise/2

Page 99

8 2955 TG PA 00

Exercice 16 Extrait du Cas SYNAPSINFO (nouméa 2007) SynapsInfo est une SSII assez importante spécialisée en informatique de gestion. Ses collaborateurs (plus de 200 salariés en décembre 2006) interviennent sur les sites de ses différents clients dans le cadre de projets. La société SynapsInfo a décidé de gérer le suivi et la rentabilité de ses contrats de prestation. La facturation de ces contrats ne fait pas partie du domaine d’étude. Gestion des clients Les clients de SynapsInfo sont des sociétés, répertoriées et classées par activité. Un client appartient à un seul secteur d’activité. Par exemple le client "BPN" appartient au secteur "Banque et Finances". On conserve le code, la raison sociale et l’adresse de chaque client. Les clients possèdent un ou plusieurs sites localisés dans des lieux géographiquement différents. Un site est caractérisé par des informations précisant sa localisation (nom du site, adresse du site) et le nom du référent opérationnel. Un numéro séquentiel permet de distinguer les différents sites d’un même client. Gestion des salariés Parmi les employés de la société SynapsInfo, on distingue deux catégories de salariés : • Les salariés chargés de l’activité commerciale. Séquence 3 Extensions sous Merise/2

Page 100

Les commerciaux démarchent et négocient les contrats de prestation auprès des entreprises clientes. Un secteur d’activité peut être prospecté par plusieurs commerciaux, mais chaque commercial est spécialisé dans un secteur d’activité. Par exemple "Loïc Morel" prospecte le secteur d’activité "Banque et Finances". Pour chaque commercial, on conserve l’objectif de ventes et le chiffre d’affaires réalisés chaque année. On mémorise également leurs coordonnées téléphoniques, fixes et portables. • Les salariés chargés des interventions chez les clients. Chaque intervenant est décrit par son niveau d’études et sa maîtrise de la langue anglaise. Il est qualifié pour intervenir sur un ou plusieurs domaines techniques. Ces domaines sont regroupés par famille technique. Le prix de journée d’un intervenant pour chaque domaine technique varie en fonction des qualifications mises en œuvre. À titre d’exemple, la liste suivante présente un extrait des compétences des intervenants : Identifiant 67

68 …

8 2955 TG PA 00

Nom prénom Dubois Pierre

Martin Julien …….

Code Domaine

Libellé du domaine

Prix par jour

Famille

DVJ2EE

Développement J2EE

620, 00 €

ADINT

DVJDBC

Développement JDBC

480, 00 €

ADINT

DVJDK

Développement JDK

460, 00 €

ADINT

DVCPP

Développement C++

370, 00 €

ACS

OSLINUX

SE Linux

410, 00 €

SERES

ADLDAP

Administration LDAP

320, 00 €

SERES

…. 

69

Durand Mélanie

DVPHP

Développement PHP

300, 00 €

ADINT

DVDEL

Développement Delphi

480, 00 €

ACS

DVCPP

Développement C++

350, 00 €

ACS

DVCSH

Développement ASP-C#

480, 00 €

ADINT

ADINT = Architecture distribuée et Internet SERES = Système d’exploitation et réseaux ACS =Architecture client-serveur et centralisée La famille technique "ADINT" regroupe les domaines techniques "DVJ2EE", "DVJDBC", "DVJDK", "DVPHP" et "DVCSH". Un domaine technique peut couvrir plusieurs domaines techniques. Par exemple  : le domaine technique "Développement J2EE" couvre les domaines techniques "Développement JDBC" et "Développement JDK". Le domaine "Développement JDBC" est aussi couvert par le domaine "Développement middleWare". Un intervenant maîtrisant le domaine technique "Développement J2EE" ou "Développement middleWare" pourra donc être sollicité sur des interventions relevant du domaine technique "Développement JDBC". La couverture d’un domaine par un autre domaine doit être mémorisée. Gestion des contrats La société SynapsInfo crée un contrat correspondant à la réalisation de prestations informatiques à la demande de l’un des sites d’une entreprise cliente. Chaque contrat est suivi par un commercial de la société SynapsInfo et placé sous la responsabilité d’un intervenant. À la négociation du contrat, le commercial fixe une enveloppe financière et un nombre de jours de prestations. Chaque contrat est rattaché au site sur lequel seront réalisées les interventions.

Séquence 3 Extensions sous Merise/2

Page 101

Exemple 1 : Le contrat 1153 signé le 5 janvier 2007 intitulé "Maintenance corrective d’applications sous PHP" ne débutera que le 1er février 2007, date prévue de début des prestations, estimées à 40 jours. Il a pour description "Évolution du module de gestion commerciale réalisé sous PHP".   Exemple 2 : Le contrat 1183 signé le 15 janvier 2007 intitulé "Audit du réseau" débutera le 18 janvier 2007 et a pour description "Auditer la sécurité du réseau local, vérifier les procédures de sauvegarde et définir les outils et procédures à mettre en œuvre pour remédier aux dysfonctionnements". La durée des prestations est estimée à 5 jours. Gestion des interventions Chaque contrat donne lieu à une ou plusieurs interventions relevant chacune d’un domaine technique. Par exemple, une intervention concernera le domaine technique "Système d’exploitation Linux" et une autre le domaine "Administration LDAP". La liste des interventions est négociée par le commercial à la signature du contrat. Il négocie également le prix de journée contractuel pour chaque intervention.

8 2955 TG PA 00

Par exemple, le contrat 1287 signé le 26 janvier 2007 intitulé  "Prestations sous Java  pour le développement d’un site Internet" comprend les interventions suivantes : Début

Fin

Prix jour

Domaine technique

No

Intitulé

État

12871

Développement des composants métiers sous J2EE

10/02/2007 30/06/2007 650,00 €

Développement J2EE

À faire

12872

Développement des accès aux données

10/02/2007 30/06/2007 520,00 €

Développement JDBC

À faire

12873

Développement de pages web clientes

15/02/2007 30/04/2007 450,00 €

Développement Java

À faire

Les dates "Début" et "Fin" correspondent aux dates prévisionnelles de début et de fin d’intervention. Une intervention est identifiée par un numéro d’ordre associé au numéro de contrat. Elle peut être dans l’état "À faire", "Planifiée", "En cours", "Interrompue", "Annulée", "Terminée", "Facturée" ou "Archivée". La phase de la planification consiste à affecter un ou plusieurs intervenants à la réalisation de chaque intervention. Pour chaque intervention planifiée, on note la date réelle de début d’intervention au démarrage de celle-ci ainsi que la date réelle de fin, après réalisation de l’intervention. Séquence 3 Extensions sous Merise/2

Page 102

Pour permettre de suivre la rentabilité de chaque intervention, on notera la durée d’affectation de chaque salarié concerné. Afin d’éviter des affectations incohérentes pour chaque intervention, il est important de prévoir des intervenants compétents dans le domaine technique correspondant.

Travail à faire Concevoir le schéma entité-association correspondant au domaine de gestion des prestations contractuelles.

8 2955 TG PA 00

Exercice 17 Extrait du Cas CREDAUTO (métropole 2006) La société CredAuto est spécialisée dans le crédit automobile accordé aux particuliers. Elle agit en partenariat avec des garagistes, établissements commercialisant des véhicules neufs ou d’occasion. Un prêt CredAuto est proposé à un particulier qui souhaite acheter un véhicule et éprouve le besoin de financer tout ou partie de cet achat. Annexe à utiliser : annexe 2 (composée de 2A et 2B). Parmi les prêts accordés par CredAuto, certains font l’objet d’échéances impayées. Lorsque le service "Suivi des prêts" constate le non-paiement d’une échéance, il transmet le dossier du "mauvais" payeur au responsable du service " Contentieux ". Remarque  Par souci de simplification, on admettra qu’une échéance ne fait jamais l’objet d’un règlement partiel. Pour chaque échéance impayée, une lettre de relance est envoyée à l’emprunteur. Au bout de trois lettres de relance restées sans effet, le dossier de prêt est envoyé au bureau "Recouvrement amiable" dépendant du service "Contentieux". L’objectif des intervenants du bureau "Recouvrement amiable" est d’éviter une procédure judiciaire et la saisie du véhicule. Si cela est possible, il est toujours préférable de trouver une solution concertée avec l’emprunteur pour obtenir le remboursement effectif du prêt. Dans ce but, le bureau "Recouvrement amiable" désigne un intervenant et lui adresse un ordre de mission (annexe 2A) sur lequel se trouvent un récapitulatif des éléments du contrat, les dates des trois dernières échéances impayées ainsi qu’un commentaire destiné à l’intervenant. Si l’ordre de mission concerne un contrat pour lequel il y a déjà eu un réaménagement du prêt, les renseignements concernant le dernier avenant sont indiqués sur l’ordre de mission.

Séquence 3 Extensions sous Merise/2

Page 103

L’intervenant du bureau "Recouvrement amiable" doit disposer des documents relatifs à l’ensemble du dossier : • le contrat de prêt et les avenants éventuels ; • la liste des incidents de paiement (dates des échéances non payées) ; • les différents courriers échangés avec l’emprunteur. L’intervenant prend alors contact par téléphone avec l’emprunteur. Si, lors de l’un des rendez-vous obtenus par l’intervenant, le client régularise les échéances impayées, l’ordre de mission est alors clos. Dans le cas contraire, l’intervenant fait une proposition de réaménagement du prêt à l’emprunteur. Le montant des échéances est alors revu à la baisse et la durée du prêt allongée. L’intervenant interroge une application du service "Suivi des prêts" qui recalcule le nouveau montant de l’échéance en fonction de la nouvelle durée et du taux du prêt. Un avenant au contrat est alors signé (annexe 2B). À l’origine d’un prêt, CredAuto n’exige jamais l’appui d’un tiers se portant caution de l’emprunteur. Mais, lors d’un réaménagement, l’intervenant du bureau "Recouvrement amiable" peut estimer que cette garantie est devenue indispensable. Il demande alors à l’emprunteur de disposer d’une ou plusieurs cautions. Une caution est une personne solidaire amenée à honorer les échéances de l’emprunteur si ce dernier ne remplit pas ses obligations.

8 2955 TG PA 00

Toutes les personnes concernées (intervenant, emprunteur, une ou plusieurs cautions) sont obligatoirement signataires de l’avenant. Le nombre des cautions n’est pas limité. Il est nécessaire de distinguer pour quel avenant la personne se porte caution et le rang auquel elle se trouve. Le rang indique l’ordre dans lequel les cautions seront sollicitées si l’emprunteur ne remplit pas ses obligations. Après signature de l’avenant par toutes les parties prenantes, l’ordre de mission est alors clos. Suite à un premier réaménagement du prêt, il arrive que celui-ci fasse l’objet de nouveaux impayés. Le responsable du service "Contentieux" peut alors confier le dossier à un autre intervenant. Dans le cas où un nouvel avenant est négocié, on admettra que l’emprunteur puisse faire appel à de nouvelles cautions, autres que celles désignées lors du précédent réaménagement. On admettra aussi qu’une caution intervenant dans un avenant n’intervienne pas forcément dans un avenant ultérieur au même contrat ou qu’elle puisse intervenir à un rang différent de l’avenant précédent. Remarque Chaque acteur est référencé de manière unique. Il peut jouer le rôle d’emprunteur dans un ou plusieurs contrats et le rôle de caution dans d’autres contrats. Si aucune solution amiable n’est trouvée, l’ensemble du dossier est transmis au service "Contentieux". L’ordre de mission est alors clos.

Séquence 3 Extensions sous Merise/2

Page 104

Le responsable du service "Contentieux" souhaite : • pouvoir enregistrer les données de l’ordre de mission (annexe 2A) ; • faire numériser l’ensemble du dossier de prêt ainsi que les courriers émis ou reçus concernant le prêt afin d’éviter le transfert de documents papier ; • conserver les informations relatives au contrat de prêt et à ses avenants. Les besoins des intervenants sont : • de gérer toutes les informations se trouvant dans l’ordre de mission (annexe 2A) et les avenants au contrat (annexe 2B) dans la future base de données ; • de mémoriser l’ensemble des documents concernant un contrat et les éditer si nécessaire ; • de faire une sélection de documents en fonction d’une date, retournant pour chacun son objet et le chemin d’accès au fichier image qui le contient.

Travail à faire 1. P  résenter un schéma entité-association du domaine "Recouvrement amiable" prenant en compte les besoins exprimés par le chef du service "Contentieux" et par les intervenants. Annexe à utiliser : annexe 3A. En fin de mois, la secrétaire reçoit les demandes de remboursement de frais de repas et de nuitée engagés par les intervenants lors de leurs déplacements. Les frais d’essence et de péage sont réglés à l’aide d’une carte de société mise à leur disposition. Un dossier mensuel de demandes de remboursement de frais est créé pour chaque intervenant lors de la saisie de sa première demande du mois. Pour chaque demande, la secrétaire enregistre autant de "notes de frais" qu’il y a de nuitées et de repas, en précisant pour chacune la date, le montant déclaré ainsi que le type (nuitée ou repas). Elle indique également la présence ou non d’un justificatif.

8 2955 TG PA 00

Si la secrétaire dispose de tous les justificatifs, le dossier mensuel de notes de frais pourra être traité  ; dans le cas contraire, elle réclame les justificatifs manquants à l’intervenant. Celui-ci dispose de quinze jours pour les lui remettre. Une analyse a permis l’élaboration d’un schéma entité-association (annexe 3A). Il est accompagné de deux règles de gestion R1 et R2 exprimées textuellement : R1  : Un intervenant travaille obligatoirement soit sur une région, soit pour une marque de véhicule, mais jamais pour les deux en même temps. R2 : Un intervenant ne peut déposer que des notes de frais dont le type lui est autorisé.

Travail à faire 2. E  n utilisant l’annexe 3A, compléter le schéma entité-association présenté pour prendre en compte les règles de gestion R1 et R2.

Annexe 2A : Ordre de mission

Séquence 3 Extensions sous Merise/2

Page 105

8 2955 TG PA 00

Annexe 2B : Avenant au contrat de prêt

Séquence 3 Extensions sous Merise/2

Page 106

Annexe 3A : Gestion des frais

Remarque : Les cardinalités (1,1) caractérisent un lien identifiant (entité dépendante).

8 2955 TG PA 00

Synthèse

Le lien identifiant Il permet schématiquement d’éliminer les entités "numéro" et la plupart des entités temporelles. Il transforme une clé étrangère en une clé primaire. Exemple d’une ancienne représentation : NUMCHAMBRE numChambre

HOTEL

CHAMBRE

1,n

0,n

type

idHotel nom adresse

Le même avec le lien identifiant : CHAMBRE

(1,1)

numChambre type

1,n

HOTEL idHotel nom adresse

Il n’y a aucune incidence sur l’écriture des relations correspondantes.

L’agrégation Elle permet schématiquement de relier 2 associations entre elles.

idVetement description

0,n

VETEMENT_TAILLE prix

Extensions sous Merise/2

Page 107

Voici la notation la plus classique de l’agrégation : VETEMENT

Séquence 3

0,n

TAILLE idTaille libellé

0,n FACTURE idFacture date

0,n

LIGNE_FACTURE quantité

Au niveau relationnel, attention à la clé étrangère double : LIGNE_FACTURE(idFacture, idVetement, idTaille, quantité) idFacture, idVetement, idTaille : clé primaire idFacture : clé étrangère en réf. à idFacture de FACTURE idVetement, idTaille : clé étrangère en réf. à (idVetement, idTaille) de VETEMENT_TAILLE

8 2955 TG PA 00

Les sous-types sur association Une association peut générer des sous-types, comme une entité. Le fonctionnement est similaire. GYMNASE

1,n

idGymnase nom adresse

PLANNING

0,n

durée

MANIFESTATION

HORAIRE date_heure

ENTRAINEMENT

titre

1,1

ORGANISATEUR idOrganisateur nom adresse Séquence 3 Extensions sous Merise/2

Page 108

1,1

0,n

SPORT 0,n

idSport nom

Les sous-types sur association restent très rares (car souvent l’association de départ peut se transformer en entité).

Les contraintes Elles permettent d’apporter des informations complémentaires sur les liens et dépendances entre les objets. Elles se traduisent généralement par des triggers dans la base de données. Plusieurs contraintes manipulent 2 notions fondamentales : –– couverture : tous les tuples sont inclus dans les objets concernés par la contrainte ; –– disjonction : aucun tuple n’est en commun dans les objets concernés par la contrainte.

Contrainte d’exclusion PERSONNEL

Exclusion = non(couverture) + disjonction. Notation : X Exemple de contrainte sur héritage : "Un personnel ne peut être à la fois administratif et professeur mais il peut être autre chose."

idPersonnel nom prenom adresse tel email

x ADMINISTRATIF dateAffectation

8 2955 TG PA 00

PROFESSEUR nbHeures

Exemple de contrainte sur association : FORMATEUR 0,n

0,n

ENSEIGNANT idEnseignant nom tel

STAGE

xX 0,n

0,n

idStage titre durée

STAGIAIRE

Pivot Entité(s) concernée(s) par la contrainte sur association. Par exemple : FORMATEUR 0,n

0,n

ENSEIGNANT idEnseignant nom tel

STAGE

x X 0,n

0,n

idStage titre durée

STAGIAIRE

Séquence 3 Extensions sous Merise/2

Les pivots sont représentés en pointillés. Ils sont toujours posés sur des entités. Ils permettent de récupérer les identifiants des entités correspondantes.

Page 109

Traduction de cette contrainte avec pivots : "Le couple (idEnseignant, idStage), s’il est présent dans FORMATEUR, ne peut être présent dans STAGIAIRE, et vice versa.". En français, cela donne : "Un enseignant ne peut pas être formateur et en même temps stagiaire à un même stage."

Contrainte de partition Partition = couverture + disjonction Notation : + (ou) XT Comme l’exclusion, elle existe sur héritage, sur association et avec des pivots.

Contrainte de totalité Totalité = couverture + non(disjonction) Notation : T Comme l’exclusion, elle existe sur héritage, sur association et avec des pivots.

Contrainte d’égalité (ou de simultanéité) Elle n’existe que sur association. Si le pivot est présent dans une des associations concernées par la contrainte, il est forcément présent dans l’autre.

8 2955 TG PA 00

SPORT PERSONNE

0,n

0,n

idSport nom

PERSONNE idPersonne nom adresse

SPORT

= 0,n

EQUIPE ÉQUIPE PERSONNE

0,n

idEquipe nom

"Une personne qui pratique un sport fait partie d’une équipe, et vice versa".

Contrainte d’inclusion Elle n’existe que sur association. Elle marque une inclusion représentée par une flèche. Tous les pivots de l’association de départ sont présents dans l’association d’arrivée. DEMANDE 0,n

0,n

PERSONNE

Séquence 3

STAGE

idPersonne nom tel

I 0,n INSCRIPTION

Extensions sous Merise/2

Page 110

0,n

idStage titre durée

présence "Une personne ne peut être inscrite à un stage que si elle en a fait la demande."

Contrainte d’inclusion à portée multiple Même principe que l’inclusion classique, excepté qu’elle peut avoir plusieurs branches pour récupérer les informations des pivots. CONDUIT

0,n

0,n

VEHICULE idVehicule immatriculation

PERSONNE

1,1

idPersonne nom adresse

I 0,n 0,n

PERMIS PERMIS PERSONNE

0,n

idPermis description

"Une personne ne peut conduire un véhicule que si elle a le permis correspondant."

8 2955 TG PA 00

Séquence 4

MCD ou Diagramme de classes ? Cette séquence présente la possibilité de modéliser les données dans un diagramme de classes en vue de la création d’une base de données.

u Prérequis Avoir totalement acquis les connaissances des séquences précédentes : savoir construire complètement un schéma conceptuel de données d’une certaine complexité et en utilisant les extensions Merise/2.

u Capacités attendues en fin de séquence Savoir modéliser les données dans un diagramme de classes. Savoir passer d’un MCD à un diagramme de classes et vice-versa. Savoir utiliser un outil de conception pour créer un diagramme de classes et générer le script de la base de données.

u Contenu 1. Pourquoi un diagramme de classes ? ............................................................. 112 2. Passage du MCD au diagramme de classes ................................................... 113 3. Utilisation d’un outil : Win’Design .................................................................. 122 4. Exercices récapitulatifs ...................................................................................... 127

Synthèse

8 2955 TG PA 00

Page 111

............................................................................. 133

8 2955 TG PA 00

1. Pourquoi un diagramme de classes ? Dans le cours 2949 "Exploitation d’un schéma de données" et dans les séquences 2 et 3 de ce cours, vous avez travaillé exclusivement avec la méthode Merise et plus précisément avec le Modèle Conceptuel de Données. Vous n’avez abordé le langage de modélisation UML que dans le cours 2950 "Programmation objet" pour apprendre la modélisation dans le domaine de la programmation objet. UML reste l’outil de modélisation idéal dans ce domaine, cependant il est aussi utilisé dans le cadre de la modélisation des données en vue de la construction d’une base de données. Généralement, cette base de données est alors exploitée par une application objet, mais ce n’est pas une obligation.

Rappel sur le langage de modélisation UML UML est un langage de modélisation qui propose 13 diagrammes et se présente depuis quelques années comme un standard dans le domaine de la modélisation.

Séquence 4 MCD ou Diagramme de classes ?

Page 112

Pourquoi UML est présenté comme un langage et non une méthode de modélisation ? Parce qu’UML présente un ensemble de diagrammes qui permettent une représentation graphique d’un aspect du réel. Chaque diagramme peut être utilisé (ou pas) de façon indépendante des autres, même s’il existe des liens entre les diagrammes. A l’opposé, Merise propose une méthode, étape par étape, pour gérer un projet d’informatisation. Cependant, excepté pour les gros projets, il est rare de suivre toutes les étapes. Du coup, pour certains, la nuance entre les deux approches est difficile à cerner. Ce qui est important, c’est de comprendre le rôle et la construction des schémas de la méthode Merise, et des diagrammes du langage UML. Vous ne devez cependant pas tout connaître dans le cadre de cette formation. Voilà pourquoi vous avez eu, dans le cours 2950 "programmation objet", une approche de certains diagrammes couramment utilisés. Dans ce cours, vous allez approfondir le diagramme de classes à partir d’une vision résolument orientée "modélisation de données".

Portée d’UML Vous pourriez vous dire : nous avons approfondi la méthode Merise et plus particulièrement le MCD en ce qui concerne la modélisation des données, alors pourquoi voir une autre modélisation pour ces mêmes données ? La réponse est simple : puisqu’il existe plusieurs modélisations possibles, autant ne pas vous limiter à un seul modèle. C’est un peu comme pour les langages de programmation : rien ne nous interdit, au niveau de cette formation, de n’aborder qu’un seul langage. Pourtant vous en avez étudié plusieurs ce qui vous a permis d’élargir vos connaissances. Mais vous remarquez que, malgré les spécificités de chaque langage, la logique de programmation reste la même : c’est d’ailleurs la logique algorithmique. Au delà de ce premier constat (diversifier ses connaissances) il y en a un second qui a peut-être encore plus de poids : UML est devenu un standard même au niveau de la modélisation des données. À ce titre, ce serait une erreur de ne pas étudier cet aspect. De nombreuses entreprises attendent des personnes qu’elles recrutent la connaissance d’UML. Enfin, dernier argument qui va dans la suite logique du précédent : UML a une portée mondiale alors que Merise n’est utilisé qu’en Europe, mais reste tout de même un standard en Europe.

8 2955 TG PA 00

Du coup, après ces explications, vous pourriez vous demander pourquoi ne pas avoir commencé à étudier en premier le diagramme de classes de façon très détaillée pour finir ensuite sur le MCD de Merise. La première raison est historique : le MCD de Merise est plus ancien et donc a fait ses preuves pendant plusieurs années, voire décennies. Il continue à l’heure actuelle à être un standard et les entreprises l’utilisent encore beaucoup. La seconde raison provient des directives données par les rédacteurs du programme du BTS SIO : actuellement, la méthode Merise reste incontournable pour modéliser les données. Officiellement dans le programme, aucun modèle n’est imposé. Cependant, à l’épreuve écrite, vous allez forcément devoir travailler sur un schéma qui sera soit partiellement présenté et à compléter, soit à construire totalement. S’il est à construire totalement, il est plus que probable que vous ayez le choix du modèle. S’il est partiellement présenté, il faudra savoir le lire, quel que soit le type de modèle : MCD ou diagramme de classes.

Apport du diagramme de classes Certains d’entre vous pensent peut-être que le diagramme de classes comme représentation des données à l’origine de la construction d’une base de données, représente juste un autre formalisme de construction d’un MCD. C’est globalement vrai, excepté les points suivants : Certains aspects du MCD ne se traduisent pas directement dans le diagramme de classes et supposent donc des choix stratégiques. Le diagramme de classes ainsi constitué ne comporte que des données. Vous savez qu’en réalité le diagramme de classes peut aussi comporter des méthodes : il n’est pas interdit de les implémenter en vue d’un développement objet, même si les classes servent ensuite à la construction d’une base de données. Ces méthodes pourront être exploitées dans l’application. La construction du diagramme de classes pour obtenir une base de données apparaît alors moins restrictive que la construction d’un MCD. Avec le diagramme de classes, non seulement il est possible de générer une base de données, mais il est possible aussi de réfléchir sur les actions qui seront faites sur les données (avec les méthodes) et, pourquoi pas de générer les classes complètes qui seront parsées avec la base de données. Voilà pourquoi, dans le cours de "programmation objet", il est précisé que le passage du MCD au diagramme de classes est possible mais pas inversement : en réalité, le passage inverse pose problème essentiellement à cause des méthodes.

Séquence 4 MCD ou Diagramme de classes ?

Page 113

2. Passage du MCD au diagramme de classes Le passage du MCD au diagramme de classes est finalement assez simple. La logique de construction au niveau des propriétés (données) et des liens entre les objets (entités) suivent une logique similaire. C’est un peu comme la traduction d’un programme de C# en Java. Ce qui compte avant tout, c’est la logique des informations et des liens entre ces informations. La suite ne va donc pas présenter comment raisonner pour organiser les données, puisque vous le savez déjà. Vous allez juste voir comment passer d’un MCD déjà construit vers un diagramme de classes.

Comment passer du MCD au diagramme de classes Pour avoir une idée précise du passage du MCD vers le diagramme de classes, voici dans un premier temps la présentation du passage de chaque cas.

8 2955 TG PA 00

Entité Une entité du MCD se traduit en classe dans le diagramme de classes. Les attributs de l’entité deviennent les propriétés de la classe. Les caractéristiques des propriétés (que l’on peut appeler aussi "attributs") sont cependant plus importantes dans le cadre d’une classe. Il est possible de choisir les caractéristiques suivantes : –– niveau de protection : privée, protégée ou publique privée (par défaut) : accessible uniquement dans la classe protégée : accessible dans la classe et les classes filles publique : accessible partout –– portée : normale ou statique (à portée de classe) portée normale (par défaut) : attribut de type "variable" portée de classe : attribut de type "constante" Vous connaissez ces caractéristiques pour les avoir étudiées dans le cours de programmation objet. Elles n’existent effectivement pas dans le cadre d’un MCD. Donc, lors du passage du MCD au diagramme de classes, les caractéristiques par défaut sont généralement gardées. Cependant, en vue d’une programmation objet, on pourrait imaginer des modifications de ces caractéristiques, suivant les besoins.

Séquence 4 MCD ou Diagramme de classes ?

Page 114

La notion d’identifiant, qui n’existe pas au niveau des propriétés d’une classe, est acceptée dans les logiciels de création de diagramme de classes (comme Win’Design) en vue de la génération d’une base de données. En revanche, même si un attribut identifiant est défini dans une classe, si celle-ci est traduite en classe de programmation, la notion d’identifiant n’a pas d’équivalent et disparaît. Enfin, il existe au niveau des classes un niveau de protection, comme pour les propriétés, qui n’existe pas au niveau du MCD. Le niveau de protection par défaut est "public", cependant rien n’interdit de choisir un autre niveau, qui n’aura aucune conséquence dans une base de données, mais qui pourrait être pris en compte lors de la génération de classes dans un programme. Exemple de passage MCD vers Diagramme de classes

MCD

Diagramme de classes

Association de type CIF Une association du MCD de type CIF (qui fait donc ressortir une dépendance fonctionnelle entre les clés de 2 entités) se traduit en une association dans le diagramme de classes, avec une propriété de type objet dans la classe d’origine. Ce qui donne une association orientée entre les 2 classes avec donc une navigabilité qui ne fonctionne que dans un sens.

8 2955 TG PA 00

Vous auriez pu penser que la traduction était plus directe (insertion dans la classe d’origine d’une propriété contenant l’identifiant de la classe de destination). Mais en objet, la notion d’identifiant n’existe pas et le but est de faire référence à un autre objet : il suffit pour cela de mémoriser la référence (l’adresse) de l’objet, d’où l’intégration d’une propriété de type objet. Cette traduction (avec une propriété objet dans la classe d’origine) est la plus stricte, mais il existe d’autres possibilités. Par exemple il n’est pas interdit de mettre en place une double navigabilité afin de pouvoir aller non seulement de la classe d’origine vers la classe destination, mais aussi dans l’autre sens. Là encore, le choix va se faire non pas en fonction de la base de données qui va être créée (car à ce niveau il n’y aura pas de différence) mais en fonction des éventuels choix qui peuvent se faire au niveau de l’application objet. Dans le diagramme de classes, la propriété de type objet n’est pas directement marquée dans la classe mais sur le lien qui la relie à la classe destination. Exemple de passage MCD vers Diagramme de classes

MCD Le rôle "lacategorie" sur le lien n’est pas du tout obligatoire, mais permet, sous un logiciel comme Win’Design, d’obtenir l’équivalence au niveau du diagramme de classes.

Séquence 4 MCD ou Diagramme de classes ?

Page 115

La flèche permet de montrer le sens de navigabilité : à partir d’un article on peut accéder à la catégorie concernée, en revanche la catégorie ne permet pas d’obtenir les articles concernés. Diagramme de classes

Cette fois la navigation est dans les deux sens. Ces deux solutions auront le même effet au niveau de la base de données. Dans certains cas, la représentation est encore plus simplifiée : la flèche (donc la navigabilité) et les rôles ne sont pas représentés. Seule la multiplicité apporte une information. Quelle que soit la solution, l’absence de nom sur le lien aura pour conséquence, au niveau de la base de données, la création d’une clé étrangère portant le même nom que la clé primaire de la table destination. Les CIF peuvent aussi se traduire par des liens d’agrégation ou de composition intraduisibles au niveau d’une base de données. Le lien d’agrégation traduit une notion de

8 2955 TG PA 00

constituant/constitué et le lien de composition, nettement plus fort, traduit une notion de composant/composé. Décider de représenter ce type de lien n’aura aucune incidence au niveau de la base de données issue du diagramme de classes, mais peut servir dans le cadre d’une programmation objet.

Association binaire non porteuse Une association binaire non porteuse du MCD se traduit en une association dans le diagramme de classes, avec une collection dans l’une ou l’autre des classes concernées (ou les 2, ce qui est le plus courant). Là encore, les collections ne seront pas traduites dans la base de données, mais pourront servir au niveau de l’application objet. Donc, contrairement à une base de données où l’association non porteuse se traduit par une table supplémentaire, dans le cadre d’une application objet elle ne donne pas naissance à une classe supplémentaire mais juste des propriétés de type collection d’objets dans l’une et/ou l’autre classes concernées. Exemple de passage MCD vers Diagramme de classes

MCD Les rôles sur les liens ne sont pas obligatoires mais permettent une récupération lors du passage au diagramme de classes sous un logiciel comme Win’Design.

Séquence 4 MCD ou Diagramme de classes ?

Page 116

Diagramme de classes

La construction de la base de données à partir de ce diagramme donnera le même résultat qu’à partir du MCD. En revanche, dans le cadre d’une programmation objet, la classe livre contiendra une propriété lesthemes qui sera une collection de Theme, et la classe Theme contiendra une propriété leslivres qui sera une collection de Livre. Ces deux propriétés permettront la navigabilité dans les deux sens entre Livre et Theme.

Association n-aire non porteuse Une association n-aire (avec n>=3) du MCD se traduit tout simplement par une association n-aire dans le diagramme de classes. L’association porte un nom car elle sera traduite en table avec une clé primaire composée de 3 attributs (ou plus), au niveau de la base de données. Au delà d’une simple traduction en association n-aire, il est possible, encore une fois, de réfléchir à un diagramme adapté à un développement objet. Dans ce cas, il est possible d’imaginer la véritable traduction de l’association, sous forme d’une nouvelle classe portant comme propriétés deux des trois objets reliés, et placer dans la classe restante une collection de cette nouvelle classe.

8 2955 TG PA 00

Exemple de passage MCD vers Diagramme de classes

MCD

Dans cet exemple, le but est de mémoriser la date de participation à des jeux de hasard, sachant qu’une personne peut participer plusieurs fois le même jour à des jeux différents et bien sûr peut participer au même type de jeu à des jours différents.

Séquence 4 MCD ou Diagramme de classes ?

Diagramme

Page 117

de classes

Dans un objectif de programmation objet, il serait alors judicieux de mettre dans la classe Personne une propriété lesparticipations qui serait une collection de Participation. La classe Participation aurait alors comme propriétés un objet de type Date et un objet de type Jeu.

Association binaire porteuse Une association binaire porteuse de données du MCD se traduit en association porteuse dans un diagramme de classes. Là encore, la traduction est directe, mais peut être affinée en vue d’un développement objet. Dans ce cas, il est possible d’imaginer 2 cas de figure : soit l’association porteuse ne possède qu’un seul attribut, soit elle en possède plusieurs. Dans le cas d’un attribut unique, l’association porteuse ne donnera pas lieu à la création d’une nouvelle classe mais juste d’une propriété de type dictionnaire dans l’une ou l’autre des classes concernées (ou les 2). La clé du dictionnaire sera une instance de la classe opposée, et le contenu sera la propriété unique issue de l’association.

8 2955 TG PA 00

Dans le cas de plusieurs attributs, il sera nécessaire de construire une nouvelle classe porteuse de ces propriétés, puis le principe est le même : le ou les dictionnaires auront pour clé une instance de la classe opposée, et pour valeur, cette fois, une instance de la classe issue de l’association. Exemple de passage MCD vers Diagramme de classes

MCD Une facture peut comporter plusieurs produits avec des quantités spécifiques pour chaque produit. Observez la cardinalité 1,n du côté de Facture pour mettre en avant le fait qu’une facture doit comporter forcément au moins un produit.

Séquence 4

Diagramme

MCD ou Diagramme de classes ?

de classes La traduction est directe. Observez la multiplicité 1..* du côté de Produit, qui traduit bien le fait qu’une facture comporte au minimum un produit (rappelez-vous que les multiplicités sont inversées par rapport aux cardinalités).

Page 118

Dans un objectif de programmation objet, cette association se traduirait par un dictionnaire lesproduits dans la classe Facture avec, pour clé, une instance de la classe Produit, et pour contenu, une propriété quantité.

Association n-aire porteuse Une association n-aire (n>=3) porteuse du MCD n’est pas complexe à traduire dans un diagramme de classes qui sert à la construction d’une base de données. C’est la combinaison de ce qui a été vu précédemment. En revanche, si le but est de réfléchir à une construction pour une application objet, il faut effectivement trouver les solutions les plus adaptées suivant le contexte. L’association donnera toujours lieu à la création d’une nouvelle classe, mais il faudra ensuite réfléchir sur la construction d’un ou plusieurs dictionnaires qui exploiteraient cette classe.

8 2955 TG PA 00

Exemple de passage MCD vers Diagramme de classes

MCD

Reprenons l’exemple précédent sur les participations aux jeux de hasard, mais cette fois, il faut mémoriser le montant misé à chaque participation et le montant gagné (qui malheureusement sera la plupart du temps nul, mais c’est une autre histoire...).

Séquence 4 MCD ou Diagramme de classes ?

Diagramme

Page 119

de classes

Rien de particulier à dire si le seul objectif est la création de la base de données. Dans un objectif de programmation objet, il est par exemple possible ici de créer une classe Participation comme préconisée dans l’exemple précédent, mais qui comportera, en plus des propriétés de type Date et de type Jeu, deux propriétés correspondant à la mise et au gain. Ensuite, le principe restera le même que dans l’exemple précédent : une collection de Participation.

Héritage L’héritage dans le MCD se traduit tout simplement par un héritage dans le diagramme de classes. Au niveau de la base de données, les mêmes choix stratégiques pourront être faits (par exemple le choix de migrer des informations pour éliminer l’héritage). Dans le cadre d’une programmation objet, il est plus rare d’éliminer un héritage qui représente un des éléments principaux de la logique objet.

8 2955 TG PA 00

Exemple de passage MCD vers Diagramme de classes

MCD

Diagramme de classes

Séquence 4 MCD ou Diagramme de classes ?

Page 120

Lien identifiant Un lien identifiant dans le MCD se traduit par un lien de composition dans le diagramme de classes. Le lien de composition représente bien cette dépendance composant/composé du lien identifiant. Exemple de passage MCD vers Diagramme de classes

MCD Dans chaque marque il existe des modèles. Le modèle est dépendant de la marque : il n’existe pas sans elle. Ici, la numérotation du modèle se fait séquentiellement en fonction de la marque.

Diagramme de classes Cette dépendance se traduit par un lien de composition.

8 2955 TG PA 00

Contraintes Les contraintes représentent des informations complémentaires qui ne se traduiront pas au niveau des données de la base de données, mais soit au niveau du programme, soit au niveau de modules (triggers) directement intégrés dans la base de données. Les contraintes vont être donc notées un peu sur le principe de commentaires au niveau du diagramme de classes. Cependant, le principe est le même que dans un MCD. Exemple de passage MCD vers Diagramme de classes

MCD

Les personnes peuvent demander une formation (association Demandeur) et, parmi les demandes, une sélection d’inscrits est faite. Donc pour être inscrit, il faut être au préalable demandeur. D’où la contrainte d’inclusion.

Séquence 4 MCD ou Diagramme de classes ?

Page 121

Diagramme de classes

La contrainte va se traduire de la même façon dans un diagramme de classes, excepté que tous les liens sont en pointillés.

Pourquoi passer du MCD au diagramme de classes Si le MCD a été construit en premier, a priori il n’y a pas de raison de le traduire en diagramme de classes avant la construction de la base de données. Cette traduction n’a d’intérêt que si le diagramme de classes est aussi exploité au niveau de l’application. Il faudra alors tenir compte des remarques précédentes pour optimiser la traduction, même si ces nuances n’ont pas d’incidence sur la base de données. On pourrait aussi se demander "pourquoi passer d’un diagramme de classes à un MCD". Il y a encore moins de raisons de faire cette traduction. En effet, ne pensez pas que pour créer une base de données il faut obligatoirement un MCD à l’origine. Un logiciel comme

8 2955 TG PA 00

Win’Design est capable de générer un modèle logique aussi bien à partir d’un MCD que d’un diagramme de classes (en réalité, il fait tout de même en arrière plan la traduction en MCD avant d’obtenir le MLD, mais c’est juste pour utiliser les modules de traduction déjà existants).

Pourquoi créer directement un diagramme de classes Compte tenu des remarques précédentes, vous l’avez compris, autant choisir soit le MCD, soit le diagramme de classes pour modéliser les données, sans penser par la suite qu’il faudra effectuer une traduction. Reste à savoir quel est le meilleur choix. Plusieurs critères sont à prendre en compte.

Contraintes de l’équipe de développement Si vous travaillez au sein d’une équipe, il n’est pas question de faire des choix qui ne sont pas en cohésion avec le reste de l’équipe. Si le développement de l’application est basé sur la méthode Merise, vous n’allez pas imposer un diagramme de classes. Au contraire, si votre chef de projet impose à l’équipe le langage de modélisation UML, vous ne modéliserez pas les données dans un MCD.

Objectifs du développement

Séquence 4 MCD ou Diagramme de classes ?

Page 122

Si l’application doit être développée en programmation objet attaquant une base de données, vous pouvez vous demander comment va s’effectuer le lien entre l’application et la base. Il est possible que l’application utilise les objets métiers qui seront liés aux informations de la base de données. Dans ce cas, un diagramme de classes est plus judicieux car certains choix, sans incidence dans la base, pourront faciliter le développement. De plus, il va être possible d’ajouter les méthodes nécessaires, inexistantes dans un MCD.

En l’absence de contrainte poussant à l’utilisation du MCD À l’heure actuelle, le diagramme de classes est plus plébiscité que le MCD, du fait qu’il est capable de remplacer totalement ce dernier et d’ajouter d’autres possibilités. C’est donc plutôt ce choix qu’il faut favoriser. Cependant le MCD reste très répandu. Peutêtre qu’en l’absence de contraintes, le choix le plus judicieux est d’utiliser ce que vous connaissez le mieux ! Mais j’insiste sur un point : l’organisation des données suit avant tout une logique qui est indépendante de la méthode choisie.

3. Utilisation d’un outil : Win’Design Comme cela a été dit plus haut, il est possible de passer directement du diagramme de classes au modèle logique et donc au script SQL à l’origine de la création de la base de données. L’outil Win’Design, que vous connaissez déjà, vous permet de construire des diagrammes de classes, de les transformer en modèles logiques, et donc de générer automatiquement le script qui permet de créer la base de données. Win’Design offre aussi les fonctionnalités qui permettent de gérer le passage du MCD au diagramme de classes et vice-versa.

Création du diagramme de classes Vous allez travailler avec Win’Design que vous avez déjà eu l’occasion de manipuler dans un précédent cours. Ouvrez le logiciel et cliquez dans l’espace de travail vide pour ouvrir la fenêtre "choix du module" (ou sélectionnez Fichier/Nouveau). Pour créer les MCD, jusqu’à maintenant

8 2955 TG PA 00

vous aviez sélectionné Database : cette fois, sélectionnez Object. Vous pouvez donner un nom de diagramme, par exemple "facturation" (en haut à gauche), puis sélectionnez "Diagramme de classes" et cliquez sur OK.

Séquence 4 MCD ou Diagramme de classes ?

Page 123

Vous avez remarqué, au passage, que Win’Design permet de modéliser plusieurs autres diagrammes du langage de modélisation UML. Une nouvelle fenêtre s’ouvre pour demander le type de langage qui devra récupérer le diagramme de classes. Ce choix permettra à Win’Design de générer le code des classes correspondantes, dans la bonne syntaxe. Vous remarquerez que, dans la liste des langages, apparaît en tête de liste, "analyse". Ce choix se détache de tout langage et se rapproche plus de la création d’un diagramme de classes afin de générer un modèle logique. Faites ce choix (qui est normalement le choix par défaut) et cliquez sur OK.

8 2955 TG PA 00

Cette fois la fenêtre de construction s’est ouverte. Une barre d’outils est mise à votre disposition, similaire à celle que vous connaissiez pour construire un MCD. Mais cette fois elle contient les outils spécifiques à la création d’un diagramme de classes. Vous y retrouvez, entre autres, les outils qui permettent de créer des classes, des associations, des classes-associations, des héritages (généralisation)... Créez une classe FACTURE. Une fois la classe créée, double-cliquez dessus pour obtenir la fenêtre de gestion de la classe (le principe est le même que pour la création d’entités).

Séquence 4 MCD ou Diagramme de classes ?

Page 124

Cliquez sur le bouton Détails. La nouvelle fenêtre permet de saisir les propriétés et méthodes de la classe. Insérez les propriétés numfacture, datefacture et total. Pour cet exemple, inutile de préciser les types, mais vous vous doutez que c’est normalement indispensable. En revanche, précisez pour numfacture que c’est un identifiant (en cochant la case correspondante)

Une fois les propriétés insérées, cliquez sur ok. La classe est créée. En suivant la même logique, créez la classe ARTICLE avec les propriétés numarticle (identifiant), nom et prix.

8 2955 TG PA 00

Une fois les deux classes créées, il est possible de les relier avec une association : sélectionnez l’outil "association" puis cliquez sur la première classe et la seconde classe. Le lien apparaît avec les multiplicités standards. Sachant qu’une facture doit comporter au moins un article, double-cliquez sur la multiplicité pour sélectionner 1..*. Une facture comporte plusieurs articles, mais avec des quantités spécifiques pour chaque article. La quantité serait placée dans une association entre Facture et Article. Il faut donc, dans le diagramme de classes, créer une classe-association : commencez par créer la classe ARTICLE_FACTURE qui ne contient que la propriété quantité, puis utilisez l’outil classe-association pour relier cette nouvelle classe au lien entre Facture et Article. Vous allez voir apparaître une ligne pointillée entre la classe et le lien. Voilà donc le résultat final pour ce petit exemple :

Séquence 4 MCD ou Diagramme de classes ?

Pensez à enregistrer votre travail. Avant de poursuivre, afin que vous ne passiez pas trop de temps à chercher lors de la construction d’autres diagrammes, sachez que pour obtenir un lien d’agrégation ou de composition, il faut double-cliquer sur la multiplicité concernée et, dans la fenêtre, sélectionner simple ou composition dans le combo agrégation.

Page 125

Du diagramme de classes à la base de données Maintenant que le diagramme de classes est construit, voyons comment obtenir le script SQL pour générer la base de données correspondante. La première étape, comme pour un MCD, consiste à générer le modèle logique. Dans le menu Modèle, sélectionnez "Générer le modèle logique". Une fenêtre apparait proposant des options de transformation. Par défaut elles sont toutes cochées. Laissez les options par défaut et cliquez sur OK. Une nouvelle fenêtre propose en particulier de choisir le SGBD : là encore, le principe est le même que lorsque vous êtes passé d’un MCD à un modèle logique de données. Remarquez au passage que, derrière la fenêtre, le MCD a été automatiquement généré : Win’Design passe par la création du MCD pour générer le MLD. Le choix du SGBD permet de préciser à Win’Design la syntaxe précise qui doit être utilisée pour générer le SQL (sachant qu’il existe des nuances d’un SGBD à un autre). Sélectionnez par exemple MySQL. Laissez les autres options par défaut et cliquez sur OK.

8 2955 TG PA 00

Vous obtenez un MLD qui doit ressembler à ceci (excepté peut-être les positions des objets, que vous pouvez d’ailleurs modifier) :

Une fois le MLD obtenu, vous savez faire : allez dans le menu "Base de données" et sélectionnez "Générer script". Dans la fenêtre, donnez le nom FACTURATION dans la partie "Code de la base" puis, dans la partie "Fichier destination", cliquez sur "Parcourir", positionnez-vous dans un dossier au choix et donnez comme nom de fichier FACTURATION.SQL. Cliquez sur ouvrir puis OK. Séquence 4 MCD ou Diagramme de classes ?

Page 126

La fenêtre de fin de génération de script apparaît. Si vous voulez, vous pouvez cliquer sur "Voir script". Vous avez alors accès au script SQL de la création de la base de données. Vous pouvez fermer la fenêtre de script.

Passage du MCD au diagramme de classes Il est possible de basculer entre MCD et diagramme de classes, dans un sens comme dans l’autre. Le principe est très simple : dans le menu Modèle, vous avez l’option "Générer le modèle conceptuel de données" quand vous êtes sur un diagramme de classes, et l’option "Générer le diagramme de classes" quand vous êtes sur un MCD. Essayez de tester dans les deux sens.

8 2955 TG PA 00

4. Exercices récapitulatifs Voici plusieurs d’exercices afin de vous familiariser avec ces notions. Pour les exercices qui demandent un passage du MCD vers le diagramme de classes et inversement, dans un premier temps, travaillez sur papier afin d’éviter que l’outil Win’Design réfléchisse pour vous. Vous pouvez ensuite, dans un deuxième temps, utiliser Win’Design pour contrôler que ce que vous avez fait est juste. Pour l’exercice portant directement sur la création d’un diagramme de classes, vous pouvez travailler directement avec Win’Design, mais en construisant directement le diagramme de classes, sans commencer par le MCD.

Traduire un MCD en diagramme de classes Exercice 1 Reprenez le MCD de la correction de l’exercice 18 de la séquence 2 et transformez-le en diagramme de classes. Voici, en rappel, ce MCD :

Séquence 4 MCD ou Diagramme de classes ?

Page 127

8 2955 TG PA 00

Exercice 2 Reprenez le MCD de la correction de l’exercice 12 de la séquence 3 et transformez-le en diagramme de classes. Voici, en rappel, ce MCD :

Séquence 4 MCD ou Diagramme de classes ?

Page 128

8 2955 TG PA 00

Interpréter un diagramme de classes et le traduire en MCD Exercice 3 Voici un diagramme de classes :

Séquence 4 MCD ou Diagramme de classes ?

Question 1 Précisez, pour chacune des informations suivantes, si elle est vrai ou fausse, en justifiant : a. Il existe plusieurs plats dans chaque catégorie. b. Une famille est numérotée par rapport à la catégorie à laquelle elle est rattachée. c. Un menu est considéré comme un produit. d. La propriété "quantité" représente la quantité de plats qui ont le même ingrédient. e. Il existe des produits autres que des menus ou des plats.

Page 129

Question 2 Traduire ce diagramme de classes en MCD (sans vous aider de Win’Design). Vous avez déjà traité quasiment le même exercice, sous un angle différent, dans une séquence précédente : faites en sorte de ne pas vous aider de votre travail précédent.

8 2955 TG PA 00

Exercice 4 Voici un diagramme de classes :

Séquence 4 MCD ou Diagramme de classes ?

Page 130

Question 1 Précisez, pour chacune des informations suivantes, si elle est vrai ou fausse, en justifiant : a. Un bilan concerne une seule mission de contrôle et une mission de contrôle peut avoir plusieurs bilans. b. Le lien qui boucle sur PLANETE traduit une association réflexive qui donnera naissance à une table contenant 2 attributs en clé primaire, faisant référence à la même table. c. Le lien de composition entre ET (Extra Terrestre) et SEJOUR montre qu’un ET effectue un seul séjour qui lui appartient. d. Tous les liens entre les classes traduisent des associations qui donneront naissance à des tables dans la base de données. e. La classe SANCTION_PRISE est une classe_association qui donnera lieu à la création d’une table dans la base de données.

8 2955 TG PA 00

Question 2 Traduire ce diagramme de classes en MCD (sans vous aider de Win’Design).

Créer un diagramme de classes pour une base de données Exercice 5 Vous faites partie d’une équipe de développeurs qui va mettre au point un nouveau jeu 3D client/serveur. Ce jeu sera accessible sur Internet. 2 joueurs pourront ainsi à distance se rencontrer dans une arène et combattre. Le site est réalisé en PHP/MySQL pour la gestion de l’inscription des joueurs, du paiement (le jeu est payant !) et des cadeaux. Une application java intégrée dans la page permet de jouer. Ce n’est que lorsqu’un joueur a payé son inscription qu’il pourra effectivement jouer. L’inscription Il faut donc mémoriser un certain nombre d’informations sur le joueur : son nom, prénom mais aussi son pseudo et mot de passe pour le jeu. Le jeu étant interdit aux moins de 12 ans, il faut connaître l’âge du joueur : il est bien sûr difficile de contrôler la véracité de cette information, cependant sa mémorisation permet d’écarter toute responsabilité de la part de la société elle-même. La date (unique) et le mode de paiement (paypal, CB…) doivent aussi être mémorisés. Les pouvoirs À tout moment, un joueur peut acheter des pouvoirs afin ensuite de les utiliser dans le jeu. Une page présente l’ensemble des pouvoirs possibles avec, pour chaque pouvoir, une photo exemple, un nom et une description détaillée et un prix (prix unitaire, pour une seule utilisation du pouvoir). Lorsqu’un joueur achète un pouvoir, il doit préciser la quantité d’utilisation qu’il désire acquérir sur ce pouvoir. Cette quantité détermine le nombre d’utilisations possibles de ce pouvoir. Il est nécessaire de mémoriser tous les achats avec en particulier la date d’achat, le mode de paiement, le pouvoir concerné et le nombre d’utilisations achetées. Un joueur ne peut pas passer plusieurs achats du même pouvoir le même jour. Certains pouvoirs sont incompatibles entre eux : un joueur ne peut pas posséder en même temps 2 pouvoirs incompatibles. Il faut donc connaître les incompatibilités.

Séquence 4 MCD ou Diagramme de classes ?

Page 131

Les cadeaux Pour fidéliser les joueurs, au delà de l’attrait du jeu lui-même, des cadeaux sont offerts. Chaque cadeau est présenté dans une page spécifique, avec sa photo, son nom, une description détaillée et le nombre de points nécessaires pour pouvoir y prétendre. Il existe 2 catégories de cadeaux : les cadeaux directement liés au jeu lui-même qui permettent d’obtenir un bouquet de pouvoirs, et les cadeaux réels qui sont physiquement expédiés aux joueurs (figurine, livre…). Les cadeaux "bouquet" : ces cadeaux offrent des pouvoirs qui vont permettre au joueur de progresser dans le jeu. Un cadeau "bouquet" contient un bouquet de pouvoirs avec, pour chaque pouvoir offert, un nombre d’utilisation. Donc, au bout d’un certain nombre d’utilisations de ce pouvoir, celui-ci va disparaître. Les cadeaux "réels" : Ces cadeaux sont directement expédiés au joueur. C’est pour cette raison que, dès l’inscription du joueur, son adresse postale lui est demandée. Son adresse email est aussi nécessaire pour la confirmation de la commande.

8 2955 TG PA 00

Les commandes de cadeaux Il est nécessaire de garder un historique des commandes de cadeaux réalisées par les différents joueurs. Les commandes sont numérotées séquentiellement par joueur. Pour chaque commande (qui peut comporter plusieurs cadeaux), le nombre total de points effectivement utilisés doit être enregistré car, au cours du temps, il est possible que les points pour chaque cadeau varient, et le calcul ne sera alors plus correct. De même, après chaque commande, le nombre de points restants pour le joueur doit être mis à jour. Ce nombre de points sera augmenté suivant le nombre de parties réalisées par le joueur, et un bonus sera donné à chaque partie gagnée : cependant vous n’avez pas à vous occuper de la gestion des parties. L’utilisation des pouvoirs Il n’est pas nécessaire de mémoriser à quel moment un pouvoir est utilisé. En revanche, il faut savoir, pour chaque joueur, le nombre d’utilisations qu’il lui reste pour chaque pouvoir qu’il possède : ces pouvoirs pouvant provenir soit d’un achat, soit d’un cadeau.

Travail à faire Créer le diagramme de classes en vue de la construction de la base de données.

Séquence 4 MCD ou Diagramme de classes ?

Page 132

8 2955 TG PA 00

TP1 Vous pouvez faire le TP1 dans le fascicule de travaux pratiques.

Synthèse

Pour construire une base de données, il est possible au préalable de construire un MCD ou un diagramme de classes. Voici les équivalences entre MCD et diagramme de classes, à manipuler tout de même avec précaution car des nuances existent entre les deux et surtout le diagramme de classes permet d’aller beaucoup plus loin, en particulier si le but final n’est pas juste la création de la base de données mais aussi la création d’une application objet.

Entité Exemple de passage MCD vers Diagramme de classes

MCD

Séquence 4 MCD ou Diagramme de classes ?

Diagramme de classes

Page 133

Association de type CIF Exemple de passage MCD vers Diagramme de classes

MCD

Diagramme de classes

8 2955 TG PA 00

Association binaire non porteuse Exemple de passage MCD vers Diagramme de classes

MCD

Diagramme de classes

Association n-aire non porteuse Exemple de passage MCD vers Diagramme de classes

Séquence 4 MCD ou Diagramme de classes ?

MCD

Page 134

Diagramme de classes

8 2955 TG PA 00

Association binaire porteuse Exemple de passage MCD vers Diagramme de classes

MCD

Diagramme de classes

Association n-aire porteuse Exemple de passage MCD vers Diagramme de classes

Séquence 4 MCD ou Diagramme de classes ?

Page 135

MCD

8 2955 TG PA 00

Diagramme de classes

Héritage Exemple de passage MCD vers Diagramme de classes

MCD Séquence 4 MCD ou Diagramme de classes ?

Page 136

Diagramme de classes

8 2955 TG PA 00

Lien identifiant Exemple de passage MCD vers Diagramme de classes

MCD

Diagramme de classes

Contraintes Exemple de passage MCD vers Diagramme de classes Séquence 4

MCD

MCD ou Diagramme de classes ?

Page 137

Diagramme de classes

8 2955 TG PA 00

Séquence 5

La programmation du SGBDR Cette séquence va nous permettre d’aller plus profondément au cœur du SGBD. C’est ici que l’on va apprendre à "scripter" en SQL "procédural". Cette séquence n’est volontairement pas orientée sur un éditeur SGBD en particulier. Le but étant de bien comprendre la programmation spécifique à un SGBD, pas de savoir programmer tel ou tel SGBD. Pour l’aspect pratique, vous aurez un TP à réaliser en fin de séquence qui vous permettra de mettre en œuvre les derniers savoirs fraîchement acquis.

u Prérequis Avoir bien compris les cours "Algorithmique appliquée" et "Bases de la programmation" de première année et en particulier les concepts de procédure, de fonction et de structure de contrôle. Il est également nécessaire d’avoir acquis les connaissances liées au langage SQL normalement vu dans les cours "Exploitation des données" et "Exploitation d’un schéma de données" en première année.

u Capacités attendues en fin de séquence Être capable de programmer dans un environnement de développement associé à un SGBD.

u Contenu

Page 139

1. La programmation procédurale des SGBDR ................................................. 140 2. Structure générale d’un programme en SQL/PSM ...................................... 140 3. Les commentaires ............................................................................................. 142 4. Affectation de variables .................................................................................. 142 5. Structures de contrôles .................................................................................... 142 6. Développement modulaire au sein du SGBDR ............................................. 145 7. Les déclencheurs ............................................................................................... 150 8. Les curseurs ....................................................................................................... 156 9. La gestion des exceptions ............................................................................... 160

Synthèse

8 2955 TG PA 00

............................................................................. 171

8 2955 TG PA 00

1. La programmation procédurale des SGBDR Le SQL dit "déclaratif" rassemble les 5 parties du langage SQL que nous avons vu jusqu’à présent : • Langage d’Interrogation de Données (LID) ; • Langage de Manipulation de Données (LMD) ; • Langage de Définition de Données (LDD) ; • Langage de Contrôle de Données (LCD) ; • Langage de Contrôle de Transactions (LCT). SQL-99 a été la révision majeure dans le monde du développement orienté base de données. C’est cette révision qui a officialisé ce que beaucoup d’éditeurs avaient déjà intégré à leurs SGBDR, la programmation procédurale1 "SQL/PSM2". Encore une fois, les éditeurs n’ayant pas attendu que la norme réponde à leurs besoins, ont implémenté leurs propres langages : • Microsoft SQL Server : T-SQL • Oracle : PL/SQL • PostgreSQL : PL/pgSQL • MySQL : SQL/PSM

Séquence 5 La programmation du SGBDR

Page 140

Tous ces langages restent toutefois très proches de ce qui est défini dans SQL/PSM de SQL-99. Un programme en SQL/PSM est structuré en blocs et peut être utilisé comme un bloc de code exécuté, comme une commande SQL ou comme une procédure stockée au sein du SGBDR.

2. Structure générale d’un programme en SQL/PSM Comme on vient de le dire, un programme en SQL/PSM est structuré en blocs : • chaque bloc commence par un "DECLARE" qui permet de définir les variables nécessaires à l’exécution du programme. C’est une clause facultative, car il peut bien évidemment y avoir des programmes sans variables locales ; • "BEGIN" marque le début d’une section exécutable. Cette section peut accueillir du code SQL/PSM et/ou du SQL déclaratif ; • la fin d’un bloc d’instructions se fait à l’aide de l’instruction "END".

Cette même révision est allée encore plus loin en fournissant aux éditeurs les préconisations de ce qui allait permettre de créer de véritables SGBDR orientés "objet" avec des concepts comme les classes, l'héritage, les types abstraits, le support d’objets complexes… Le relationnel-objet n’étant pas au référentiel du BTS, nous ne l’étudierons pas dans le cadre de ce cours.

1.

2.

8 2955 TG PA 00

PSM : Persistent Stored Modules que l’on peut traduire par "procédures stockées".

DECLARE Cette clause, facultative rappelons-le, permet comme son nom l’indique de déclarer des variables. • Par exemple si l’on a besoin d’un compteur de type entier : DECLARE compteur INTEGER ;

• On peut également déclarer plusieurs variables ("nom" de type chaîne de caractères) dans une même clause DECLARE. Il convient alors d’indenter le code pour plus de lisibilité : DECLARE compteur INTEGER ; nom VARCHAR(25) ;

Il n’y a pas de point-virgule après un "DECLARE" qui permet d’indiquer le début du bloc des déclarations. Par convention, il est recommandé de nommer ses objets en fonction de leur utilité : • variable ("v_...") ; • curseur ("c_...") ; • paramètre d’entrée ("i_...") ; • paramètre d’entrée-sortie ("io_...") ; • paramètre de sortie ("o_..."). Séquence 5 La programmation du SGBDR

BEGIN/END Ces clauses (obligatoires) permettent d’indiquer au moteur d’exécution le début et la fin du bloc dit "exécutable", c’est dire celui qui contiendra les instructions SQL et/ou SQL/ PSM. •

Page 141

Toujours dans un souci de lisibilité, il est d’usage d’indenter tout ce qui se trouve entre le "BEGIN" et le "END" : BEGIN ...; END;

Il n’y a pas de point-virgule après un "BEGIN" qui permet d’indiquer le début du bloc exécutable, en revanche, il y en a bien un après le "END".

3. Les commentaires Il n’est plus nécessaire de justifier l’utilisation de commentaires dans les programmes. Quiconque ayant déjà "développé" sait qu’ils sont essentiels et incontournables. En SQL/PSM et dans la plupart des langages procéduraux implémentés par les éditeurs de SGBDR : • une ligne de commentaires commence par "--" ; • un commentaire qui doit s’étendre sur une ou plusieurs lignes doit se situer dans un bloc qui commence par "/*", et qui se termine par "*/".

8 2955 TG PA 00

4. Affectation de variables Comme on l’a vu au point 2, la déclaration des variables se fait dans le bloc "DECLARE". • L’affectation d’une valeur peut se faire à la déclaration d’une variable. Par exemple si l’on veut initialiser la variable "v_untour" à "360" : DECLARE v_untour INTEGER DEFAULT 360 ; ...

• L’affectation d’une valeur peut également se faire dans le bloc exécutable avec l’instruction "SET" et l’opérateur ":=" : ... BEGIN SET v_untour := 360 ; ... END ;

5. Structures de contrôles SQL/PSM nous fournit les mêmes structures de contrôles que dans n’importe quel autre langage procédural. Séquence 5 La programmation du SGBDR

Page 142

IF … END IF Il y a plusieurs utilisations possibles de la structure conditionnelle "IF" en fonction du nombre de cas à traiter. • S’il y a une seule action à réaliser lorsque la condition est vérifiée. Par exemple, si la variable "v_annee" contient une valeur égale à "2011", on réalise l’action "action1" : IF (v_annee = 2011) THEN action1... ; END IF ;

• S’il y a une action à réaliser lorsque la condition est vérifiée et une autre si elle ne l’est pas. Par exemple, si l’année n’est pas égale à "2011", on souhaite réaliser l’action "action2" : IF (v_annee = 2011) THEN action1... ; ELSE action2... ; END IF ;

• S’il y a une action à réaliser lorsque la condition est vérifiée et d’autres conditions à vérifier ainsi que d’autres actions à réaliser si elle ne l’est pas. Par exemple si l’"année" n’est pas égale à "2011", mais qu’elle est égale à "2012", on maintient l’action "action2", sinon on réalise l’action "action3" :

8 2955 TG PA 00

IF (v_annee = 2011) THEN action1... ; ELSEIF (v_annee = 2012) THEN action2... ; ELSE action3... ; END IF ;

CASE … END CASE Cette structure conditionnelle permet d’effectuer de nombreuses vérifications de conditions, sans pour autant avoir à multiplier les structures "IF". • Reprenons l’exemple de l’année. Cette fois-ci on souhaite reprendre les conditions précédentes et y adjoindre la suivante  : si l’année n’est pas égale à "2012", mais qu’elle est égale à "2013" on souhaite réaliser l’action "action4" : CASE v_annee WHEN 2011 THEN WHEN 2012 THEN WHEN 2013 THEN WHEN 2013 THEN END CASE ;

action1... ; action2... ; action3... ; action4... ;

• On souhaite à présent que l’action "action5" soit réalisée dans tous les autres cas : CASE v_annee WHEN 2011 THEN action1... ; WHEN 2012 THEN action2... ; WHEN 2013 THEN action3... ; WHEN 2013 THEN action4... ; ELSE action5... ; END CASE ;

Séquence 5 La programmation du SGBDR

WHILE … DO … END WHILE

Page 143

Cette structure (qui correspond au "TantQue / FinTantQue" qui a dû être vu en algorithmique) permet d’effectuer des itérations si une condition "d’entrée" est vérifiée. • Par exemple si l’on veut que l’action "actionX" soit réalisée tant que la variable "v_mavaleur" est inférieure ou égale à 10 : WHILE (v_mavaleur = 10) THEN EXIT ; END IF ; END LOOP ;

FOR … IN … LOOP … END LOOP Séquence 5

Cette structure (qui correspond au "Pour / FinPour" qui a dû être vu en algorithmique) permet d’effectuer un nombre d’itérations prévu à l’avance. • Par exemple si l’on veut que l’action "actionX" soit réalisée 10 fois : FOR v_mavaleur IN 1..10 LOOP actionX... ; END LOOP ;

La programmation du SGBDR

Page 144

À la première itération, "v_mavaleur" contient "1". À chaque itération, "v_mavaleur" est incrémenté de "1", jusqu’à atteindre "10". Lorsque "v_mavaleur" arrive à "10", une ultime itération est effectuée.

Exercice 1 Créer un programme qui permet d’afficher une table de multiplication (jusqu’à 10), en fonction de la valeur d’une variable initialisée au départ. L’opérateur SQL "||" permet de concaténer le contenu de variables). Pour un nombre de départ à 5, l’affichage demandé est le suivant : 1x5=5 2 x 5 = 10 …

8 2955 TG PA 00

6. Développement modulaire au sein du SGBDR Comme dans les autres langages procéduraux, SQL-99 nous offre la possibilité de faire du développement modulaire en créant des procédures ou des fonctions. La liste des avantages du développement modulaire est longue : • possibilité de créer des bibliothèques de modules réutilisables ; • délocalisation des traitements ; • meilleure lisibilité par un gain de lignes ; • diminution du risque d’erreur par un débogage facilité et une simplicité d’entretien ; • découpage logique des fonctionnalités ; • travail en équipe favorisé par la délégation des tâches de développement… Et plus spécifiquement dans le cadre des bases de données, l’utilisation du développement modulaire permet d’accroître la rapidité d’exécution, car les procédures et fonctions sont au préalable stockées et compilées dans le SGBDR (diminution des échanges réseau, et temps d’exécution réduits), d’accroître la sécurité en ayant la possibilité d’accorder ou non des privilèges sur ces modules stockés et enfin d’améliorer l’intégrité (chaque fonction et procédure stockée est lancée dans le cadre d’une transaction dans le niveau d’isolation courant).

Procédure stockée Comme vous avez dû le voir en algorithmique, une procédure est un module qui fait quelque chose. SQL/PSM nous permet de créer une procédure stockée avec l’instruction "CREATE PROCEDURE" et ensuite de pouvoir l’appeler avec l’instruction "EXECUTE". • On souhaite par exemple créer une procédure qui va afficher si l’on se trouve dans un jour pair ou impair. Nous disposons des fonctions SQL suivantes : –– "CURRENT_DATE" : qui retourne la date courante ; –– "EXTRACT(DAY FROM DATE ‘unedate’)" : qui retourne uniquement le numéro de jour à partir de la date "unedate".

Séquence 5 La programmation du SGBDR

Page 145

CREATE PROCEDURE jourPairOuImpair() DECLARE v_numJour INTEGER ; BEGIN SELECT EXTRACT(DAY FROM DATE (CURRENT_DATE)) INTO v_numJour ; IF (v_numJour % 2) = 0 THEN SELECT ‘Pair’ ; ELSE SELECT ‘Impair’ ; END IF ; END ;

"INTO" nous permet de placer le résultat de la requête dans la variable "v_numJour" afin de pouvoir nous en resservir dans la suite du programme. • Il suffit ensuite de l’appeler pour afficher soit "Pair" soit "Impair" : CALL jourPairOuImpair() ;

La notion de "procédure" n’existe pas sous PostgreSQL qui considère que les procédures sont des fonctions qui ne renvoient rien ("void").

8 2955 TG PA 00

Fonction stockée Comme vous avez dû le voir en algorithmique, une fonction renvoie quelque chose. SQL/ PSM nous permet de créer une fonction stockée avec l’instruction "CREATE FUNCTION" à laquelle il faut obligatoirement adjoindre la clause "RETURNS" qui permet de déclarer le type de retour. Il faut également qu’il y ait un "RETURN" dans le bloc exécutable qui retourne une valeur du type spécifié dans la déclaration faite avec la clause "RETURNS" • Reprenons l’exemple précédent, à la différence près que cette fois, on souhaite que la fonction nous retourne les valeurs "Pair" ou "Impair" : CREATE FUNCTION jourPairOuImpair() RETURNS VARCHAR(6) DECLARE v_numJour INTEGER ; BEGIN SELECT EXTRACT(DAY FROM DATE (CURRENT_DATE)) INTO v_numJour ; IF (v_numJour % 2) = 0 THEN RETURN ‘Pair’ ; ELSE RETURN ‘Impair’ ; END IF ; END ;

• Il suffit ensuite d’utiliser notre fonction comme on le ferait avec une fonction intégrée au SGBDR : SELECT jourPairOuImpair() ;

Séquence 5 La programmation du SGBDR

 a déclaration de la fonction ci-dessus est conforme à SQL-99 mais doit être légèrement L adaptée pour être utilisée sous PostgreSQL. Ce dernier étant capable de travailler avec de nombreux langages (PL/pgSQL, PL/Tcl, PL/Python, PL/Perl…) il faut impérativement lui préciser quel interpréteur appeler :

Page 146

CREATE FUNCTION jourPairOuImpair() RETURNS character varying AS $monCode$ DECLARE v_numJour INTEGER ; BEGIN SELECT EXTRACT(DAY FROM DATE (CURRENT_DATE)) INTO v_numJour ; IF (v_numJour % 2) = 0 THEN RETURN ‘Pair’ ; ELSE RETURN ‘Impair’ ; END IF ; END ; $monCode$ LANGUAGE PLPGSQL ;

Vous noterez que le code de notre programme a été délimité à l’aide de deux caractères "$" (dollar). L’intitulé "monCode" n’est absolument pas obligatoire, on peut même ne rien mettre pour définir la délimitation ($$).

8 2955 TG PA 00

Pour créer cette fonction sous pgAdmin, il y a plusieurs solutions : – soit on place son code directement dans l’outil "Query" en utilisant ensuite l’exécuteur pgScript3 ; – soit on peut utiliser l’assistant graphique "Ajouter une fonction…" :

Clic droit sur l’item "Fonctions" et choisir "Ajouter une fonction" ê

è

Saisir le nom de la fonction (en minuscules)

è

Aller dans l’onglet "Définition" et choisir le type renvoyé ainsi que le langage utilisé

Insérer ensuite le code dans l’onglet du même nom et valider

Séquence 5 La programmation du SGBDR

Le passage de paramètre Comme vous avez également dû le voir en algorithmique, un module (fonction ou procédure) peut se voir passer des paramètres. • Chaque paramètre peut être passé selon un certain mode : –– "IN"  : Paramètre en "entrée", également appelé "passage par valeur". La valeur du paramètre est recopiée dans une zone mémoire utilisable librement à l’intérieur du module. Les modifications sont possibles sans aucune incidence à l’extérieur du module ; –– "INOUT"  : Paramètre en "entrée-sortie", également appelé "passage par référence". Ici, c’est la référence de la zone mémoire de la variable qui est passée au module. À l’intérieur du module on peut donc manipuler librement le contenu réel de la variable. Toutes les modifications effectuées ont une incidence à l’extérieur du module ; –– "OUT"  : Paramètre en "sortie". Cela permet de fournir au module des variables où l’on va uniquement écrire, elles n’ont même pas à être initialisées. • Reprenons l’exemple précédent, à la différence près que cette fois, l’on souhaite créer une fonction générique réutilisable qui retourne les valeurs "Pair" ou "Impair" selon si le paramètre "i_nombre" est pair ou impair :

Page 147

3. Touche F6 ou bouton

8 2955 TG PA 00

CREATE FUNCTION jourPairOuImpair(i_nombre IN INTEGER) RETURNS VARCHAR(6) BEGIN IF ((i_nombre % 2) = 0) THEN RETURN ‘Pair’ ; ELSE RETURN ‘Impair’ ; END IF ; END ;

 our pouvoir déclarer des paramètres graphiquement sous pgAdmin, il faut se rendre dans P l’onglet "Paramètres" et déclarer les paramètres désirés :

è

Renseigner le type du paramètre, le mode de passage, le nom et terminer l’ajout en cliquant sur "Ajouter".

La fonction est dès lors "paramétrée".

Séquence 5 La programmation du SGBDR

• Il suffit ensuite d’utiliser notre fonction en lui passant un entier : SELECT jourPairOuImpair(15) ;

Page 148

• On peut bien évidemment combiner les fonctions que l’on a créées avec celles fournies par le SGBDR. Par exemple si l’on veut utiliser notre fonction avec le jour courant : SELECT jourPairOuImpair( EXTRACT(DAY FROM DATE (CURRENT_DATE)) ) ;

8 2955 TG PA 00

Exercice 2 • Écrire une procédure qui permet d’afficher un caractère un certain nombre de fois. Le caractère et le nombre de fois, sont fournis. • Créer une fonction qui retourne le prix à payer en fonction d’un poids fourni. La société utilise les services d’un transporteur pour assurer la livraison des commandes auprès des clients qui le souhaitent. Les tarifs sont les suivants : –– tarif 1 : 1,50 € par kg ; –– tarif 2 : 1,00 € par kg ; –– tarif 3 : 0,50 € par kg. Le montant HT est calculé en appliquant les règles suivantes : –– si le poids est inférieur ou égal à 10 kg : le tarif 1 est appliqué sur ce poids ; –– si le poids est inférieur ou égal à 100 kg : le tarif 1 est appliqué jusqu’à 10 kg, puis sur la tranche restante, on applique le tarif 2 ; –– pour un poids supérieur à 100 kg : le tarif 1 est appliqué jusqu’à 10 kg, puis le tarif 2 sur la tranche jusqu’à 100 kg, et enfin sur la tranche restante, on applique le tarif 3. Exemple : Un colis de 125 kg coutera 117,50 € HT è (10 x 1,5) + (90 x1) + (25 x 0,5) = 117,5

7. Les déclencheurs

4

Séquence 5

Arrivée avec SQL-99, l’instruction "CREATE TRIGGER" permet de définir et d’associer des déclencheurs à une table. Un déclencheur permet d’exécuter un ensemble de commandes lorsqu’une instruction "INSERT", "DELETE" ou "UPDATE" est émise sur la table où a été défini le déclencheur. Les déclencheurs permettent d’assurer la mise en œuvre des règles de gestion, et comme en programmation évènementielle, permettent d’associer un évènement à une action à réaliser avant ou après l’évènement déclencheur.

La programmation du SGBDR

Page 149

Évènement déclencheur  L’action prédéfinie d’un déclencheur s’exécute lorsque l’évènement pour lequel il a été conçu se réalise. Ces évènements sont soit : –– "INSERT" : Le déclencheur se lance si l’insertion d’une ou plusieurs lignes est effectuée sur la table à laquelle il a été associé ; –– "UPDATE" : Le déclencheur se lance si la mise à jour d’une ou plusieurs lignes est effectuée sur la table à laquelle il a été associé ; –– "DELETE" : Le déclencheur se lance si l’effacement d’une ou plusieurs lignes est effectué sur la table à laquelle il a été associé.

4 "Déclencheur" qui est la traduction de "trigger" en anglais.

8 2955 TG PA 00

Chronologie de déclenchement  Lorsqu’un déclencheur est créé, le développeur peut choisir soit : –– "BEFORE"  : Afin d’effectuer des actions avant que l’évènement déclencheur soit réalisé ; –– "AFTER" : Pour que les actions du déclencheur soient réalisées après celle de l’évènement déclencheur. Par exemple si l’on veut créer un déclencheur "mondeclencheur" associé à la table "commande" qui s’exécutera avant toute mise à jour : CREATE TRIGGER mondeclencheur BEFORE UPDATE ON commande BEGIN ... END ;

Ici, le déclencheur s’activera lorsqu’une instruction de type "UPDATE" sur la table "commande" sera détectée. Les instructions situées dans le bloc exécutable seront alors réalisées avant celles qui ont activé le déclencheur ("BEFORE UPDATE").

Nombre de déclenchement  Séquence 5 La programmation du SGBDR

Page 150

Comme on l’a vu à de nombreuses occasions, lorsqu’on lance une requête d’insertion, de mise à jour ou de suppression, l’on peut affecter un nombre considérable de lignes. Par défaut les déclencheurs ne se lancent qu’une seule fois, avant ou après, mais qu’une seule fois pour une requête. SQL/PSM nous permet toutefois de configurer un déclencheur pour que les actions prévues soient réalisées pour chaque ligne insérée, mise à jour ou supprimée grâce à la clause "FOR EACH ROW". • Par exemple si l’on veut créer un déclencheur "mondeclencheur" associé à la table "article" qui s’exécutera avant toute suppression et pour chaque article supprimé : CREATE TRIGGER mondeclencheur BEFORE DELETE ON article FOR EACH ROW BEGIN ... END ;

orsque plusieurs déclencheurs ayant les mêmes caractéristiques existent (table, évèO Lnement déclencheur et chronologie de déclenchement identiques) il faut consulter l’aide du SGBD ciblé pour savoir comment est déterminé l’ordre de lancement de ces déclencheurs. Par exemple sous PostgreSQL, les déclencheurs ayant les mêmes caractéristiques sont lancés en suivant l’ordre alphabétique de leurs noms ; sous SQL Server il est possible de définir un premier et un dernier mais s’il y en a plus de deux, l’ordre est alors aléatoire ; et enfin sous Oracle, l’ordre est décidé arbitrairement par le SGBD et cet ordre n’est pas prévisible…

8 2955 TG PA 00

Interagir avec les lignes affectées par les évènements déclencheurs  omme vous avez vu en cours d’exploitation des données, lorsque l’on effectue une modiC fication de données en SQL LMD (INSERT, UPDATE, DELETE) la table possède un état "avant", et un état "après" : Ajout :

TABLE uneTable



Opération conceptuelle



Mise à jour :

TABLE uneTable



Opération conceptuelle

état avant

état après

état après

Suppression :

TABLE uneTable



état avant

Opération conceptuelle

SQL/PSM nous fournit deux alias de ligne "OLD" et "NEW" qui, dans les opérations d’ajout, de mise à jour et de suppression, vont respectivement contenir la ligne dans son "état avant" et dans son "état après". Toutefois, en fonction de l’action réalisée, le déclencheur ne pourra pas avoir accès à l’un ou à l’autre des alias : • l’ajout ne dispose que de "NEW" ; • la mise à jour dispose des deux ; • la suppression ne dispose que de "OLD".

Séquence 5 La programmation du SGBDR

Page 151

• Imaginons par exemple que l’on souhaite pouvoir tracer les insertions de la table "commande". Pour cela on dispose d’une table "log". On souhaite qu’à chaque nouvelle commande, une ligne contenant l’"idVendeur" ainsi que la date et l’heure courante soit insérée dans la table "log" : CREATE TRIGGER traceCommandes AFTER INSERT ON commande BEGIN INSERT INTO log VALUES (NEW.idvendeur , CURRENT_TIMESTAMP) ; END ;

La notation pointée est ici obligatoire, car l’alias "NEW" contient la ligne qui a été ajoutée (elle l’est déjà, car on a utilisé "AFTER INSERT") et une ligne est composée de champs. "NEW.idvendeur" fait donc référence au champ idvendeur de la table "commande".

8 2955 TG PA 00

• On souhaite à présent que la quantité disponible d’articles soit automatiquement décrémentée de la quantité mentionnée lors du passage d’une commande : CREATE TRIGGER majqteDispo AFTER INSERT ON lignecommande FOR EACH ROW BEGIN UPDATE article SET qtedispo = qtedispo - NEW.qtecde WHERE idmeuble = NEW.idmeuble ; END ;

Au point précédent on a vu que sauf indication contraire, les actions d’un déclencheur ne sont réalisées qu’une fois pour la globalité de l’évènement déclencheur. Or ici, une commande peut comporter plusieurs articles, ce qui veut dire qu’il faudra mettre à jour la quantité disponible pour chaque article. Il ne faudra donc pas oublier de rajouter la clause "FOR EACH ROW" (sinon c’est le comportement par défaut "FOR EACH STATEMENT", c’est-à-dire "une fois par instruction" qui sera utilisé). • N’oublions pas que dans le bloc exécutable on a parfaitement le droit d’utiliser des structures de contrôles. Par exemple lorsqu’un client cumule 500 € de commandes de meubles, il doit automatiquement pouvoir disposer d’une ristourne de 10% sur sa prochaine commande. Dans la base de données, cela se traduit par le fait de positionner le champ booléen "Ristourne" à "vrai" : Séquence 5 La programmation du SGBDR

Page 152

CREATE TRIGGER ristourneouinon AFTER INSERT ON commande DECLARE v_caclient DECIMAL(5,2) ; BEGIN /* Récupération du montant total dépensé par le client concerné par cette nouvelle commande */ SELECT SUM(totalcde) INTO v_caclient FROM commande WHERE idClient = NEW.idClient ; /* Si le montant total dépensé est supérieur ou égal à 500 €, on passe la ristourne à "vrai" */ IF (v_caclient >= 500) THEN UPDATE client SET ristourne = TRUE WHERE idClient = NEW.idClient ; END IF ; END ;

8 2955 TG PA 00

• Rien ne nous empêche d’appliquer les préceptes du développement modulaire dans un déclencheur. Par exemple ici, nous allons créer la fonction "retournecaclient" qui retournera le montant total dépensé par le client dont l’"idClient" est passé en paramètre : CREATE FUNCTION retournecaclient (IN i_idCli INTEGER) RETURNS DECIMAL(5,2) DECLARE v_caclient DECIMAL(5,2) ; BEGIN /* Récupération du montant total dépensé par le client passé en paramètre */ SELECT SUM(totalcde) INTO v_caclient FROM commande WHERE idClient = i_idCli ; -- La fonction retourne le montant total calculé RETURN v_caclient ; END ;

• Ce qui nous permet de modifier le déclencheur "ristourneouinon" afin d’utiliser notre nouvelle fonction : CREATE TRIGGER ristourneouinon AFTER INSERT ON commande BEGIN /* Si le montant total dépensé est supérieur ou égal à 500 €, on passe la ristourne à "vrai" */ IF (retournecaclient(NEW.idClient) >= 500) THEN UPDATE client SET ristourne = TRUE WHERE idClient = NEW.idClient ; END IF ; END ;

Séquence 5 La programmation du SGBDR

Page 153

Exercice 3 Créer un déclencheur qui retire automatiquement 10% du "montantTotal" d’un achat lorsque l’on est le premier jour du mois.

La gestion des déclencheurs sous PostgreSQL Prenons juste quelques minutes pour voir comment sont gérés les déclencheurs sous PostgreSQL. Sous PostgreSQL la gestion des déclencheurs est très particulière. Pour créer un déclencheur il faut procéder en deux temps : –– créer une fonction (CREATE FUNCTION) sans arguments avec une valeur de retour de type "trigger" ; –– créer un déclencheur (CREATE TRIGGER) au sein duquel est appelée la fonction créée à l’étape précédente (EXECUTE PROCEDURE).

8 2955 TG PA 00

Par exemple pour créer le trigger "ristourneouinon" sous PostgreSQL, il faudra d’abord créer la fonction "ristourneouinon" : CREATE FUNCTION ristourneouinon() RETURNS TRIGGER AS $monCode$ BEGIN /* Si le montant total dépensé est supérieur ou égal à 500 €, on passe la ristourne à "vrai" */ IF (retournecaclient(NEW.idClient) >= 500) THEN UPDATE client SET ristourne = TRUE WHERE idClient = NEW.idClient ; END IF ; RETURN NEW ; END ; $monCode$ LANGUAGE PLPGSQL ;

Ensuite il suffira de créer le déclencheur "ristourneouinon" au sein duquel sera appelée la fonction "ristourneouinon" : CREATE TRIGGER ristourneouinon AFTER INSERT ON commande FOR EACH ROW EXECUTE PROCEDURE ristourneouinon();

8. Les curseurs5 Séquence 5 La programmation du SGBDR

Page 154

Pour l’instant, dans nos blocs exécutables nous avons initialisé des variables uniquement avec des requêtes qui retournaient une ligne unique, c’était donc facile de les utiliser directement avec des variables "standard". Mais en développement orienté base de données, il arrive fréquemment que l’on ait à manipuler individuellement chaque ligne retournée par une requête. C’est là qu’intervient le curseur qui stocke en cache uniquement la ligne courante du résultat d’une requête et va permettre de travailler "ligne par ligne". Ce mécanisme présente de nombreux avantages dont celui d’éviter de surcharger la mémoire quand le résultat contient un grand nombre de lignes. L’utilisation d’un curseur demande le respect de quatre étapes bien distinctes. Déclaration : il y a 2 choses à prendre en compte dans la déclaration et l’utilisation d’un curseur : –– le curseur, qui se déclare comme une variable "standard" dans le bloc de déclaration et permet de mémoriser la requête qui sera exécutée à l’ouverture du curseur ; –– les variables qui accueilleront les valeurs à récupérer dans le curseur. Par exemple si l’on veut travailler sur tous les meubles de la base de données : DECLARE c_moncurseur CURSOR FOR SELECT idMeuble,descMeuble,prixMeuble FROM meuble ; v_idMeuble VARCHAR(6) ; v_descMeuble VARCHAR(25) ; v_prixMeuble DECIMAL(5,2) ; 5 Vous avez normalement abordé les curseurs dans le cours "Developpement d'application" en première année. C'est le même philosophie, à la différence près qu'ici, l'écriture se fait intégralement en SQL.

8 2955 TG PA 00

Ouverture : l’ouverture du curseur provoque l’exécution de la requête et place le curseur automatiquement à la première ligne du tableau : ... BEGIN OPEN c_moncurseur ;

Parcours  : une fois le curseur ouvert et positionné sur la première ligne, on peut lire son contenu grâce à l’instruction "FETCH". Cette instruction permet non seulement de lire la ligne courante du curseur, mais elle permet également, une fois la ligne lue, de positionner le curseur sur la ligne suivante : ... FETCH c_moncurseur INTO v_idMeuble, v_descMeuble, v_prixMeuble; /* Dès lors les 3 variables comportent respectivement le contenu des champs "idMeuble", "descMeuble" et "prixMeuble" de la ligne en cours du curseur */

Fermeture  : la fermeture d’un curseur libère des ressources mobilisées par le curseur (résultats et verrous sur la ligne en cours). ... CLOSE c_moncurseur ; ... END ;

La fermeture d’un curseur n’implique pas sa fermeture définitive. Il peut être à nouveau ouvert avec l’instruction "OPEN" et parcouru avec "FETCH".

Séquence 5 La programmation du SGBDR

Parcours un curseur  Parcourir un curseur implique de faire des répétitions. Et comme toute structure répétitive, il faut avoir une condition de sortie. Dans notre cas la condition paraît évidente : la fin de curseur. Seulement comment faire ? Il va falloir utiliser un mécanisme que nous étudierons plus loin, la gestion des exceptions. • On souhaite par exemple parcourir notre curseur, tant qu’il n’est pas vide. Nous allons pour cela utiliser la structure "WHILE … DO … END WHILE" en spécifiant comme condition d’entrée, que le curseur ne soit pas vide :

Page 155

... WHILE (NOT v_curseurvide) DO FETCH moncurseur INTO ... ; ... END WHILE ; ...

• Pour pouvoir utiliser "curseurvide", il faut l’avoir au préalable déclaré comme une variable booléenne qui contiendra "vrai" si le curseur est vide (fin de curseur atteint) ou "faux" sinon : DECLARE v_curseurvide BOOLEAN DEFAULT FALSE ;

8 2955 TG PA 00

• Il faut également qu’un gestionnaire d’exception soit déclaré, qu’il soit configuré pour intercepter l’exception "NOT FOUND", et que celle-ci ait pour conséquence le passage à "VRAI" de la variable "v_curseurvide" : DECLARE v_curseurvide BOOLEAN DEFAULT FALSE ; CONTINUE HANDLER FOR NOT FOUND SET v_curseurvide := TRUE ;

Exemple de mise en œuvre d’un curseur On souhaite par exemple afficher tous les vendeurs qui ont vendu au moins 500 meubles pour un montant total d’au moins 7 500 €. • On pourrait tout faire avec une requête d’interrogation, mais du fait de sa complexité elle serait extrêmement consommatrice de ressources :

Séquence 5 La programmation du SGBDR

Page 156

SELECT vendeur.idvendeur, nomvendeur, prenomvendeur, nbmeublesvendu, carealise FROM vendeur NATURAL JOIN ( SELECT idvendeur, SUM(qtecde) AS nbmeublesvendu FROM commande NATURAL JOIN lignecommande GROUP BY idvendeur ) ventesmeubles NATURAL JOIN ( SELECT idvendeur, SUM(totalcde) AS carealise FROM commande GROUP BY idvendeur ) cavendeur HAVING nbmeublesvendu >= 500 AND carealise >= 7500 ;

• Nous allons donc utiliser un curseur qui va nous permettre de ne lancer la comptabilisation du nombre de meubles vendus, que si le chiffre d’affaires réalisé est déjà d’au moins 7 500 € : DECLARE c_moncurseur CURSOR FOR SELECT idvendeur, SUM(totalcde) FROM commande GROUP BY idvendeur ; v_curseurvide BOOLEAN DEFAULT FALSE ; CONTINUE HANDLER FOR NOT FOUND SET v_curseurvide := TRUE ; v_nbmeublesvendu INTEGER ; v_carealise DECIMAL(5,2) ; BEGIN -- Ouverture du curseur OPEN c_moncurseur ; WHILE (NOT v_curseurvide) DO /* On lit la ligne courante et on passe à la suivante */ FETCH c_moncurseur INTO v_idvendeur, v_carealise;

8 2955 TG PA 00

/* Si le CA réalisé est d’au moins 7500 € on comptabilise le nombre de meubles vendus */ IF (v_carealise >= 7500) THEN SELECT SUM(qtecde) INTO v_nbmeublesvendu FROM commande NATURAL JOIN lignecommande WHERE idvendeur = v_idvendeur  GROUP BY idvendeur ; /* Si en plus de la condition précédente le nombre de meubles vendus est d’au moins 500 on affiche les vendeurs et les résultats */ IF (v_nbmeublesvendu >= 500) THEN SELECT idvendeur,nomvendeur,prenomvendeur v_nbmeublesvendu,v_carealise FROM vendeur WHERE idvendeur = v_idvendeur ; END IF ; END IF ; END WHILE ; CLOSE c_moncurseur ; -- On ferme le curseur END ;

PostgreSQL (et d’autres) a de son côté simplifié la mise en œuvre des curseurs permettant aux développeurs de travailler directement avec les curseurs, sans avoir à passer par des variables d’accueil. De plus, une structure itérative de type "FOR" a été implémentée pour permettre l’ouverture, le parcours et la fermeture automatique d’un curseur sans que le développeur n’ait à se soucier de la gestion du curseur. • Voilà ce que donnerait un extrait du programme précédent en PL/pgSQL sous PostgreSQL (nécessairement à l’intérieur d’une fonction ou d’une transaction) : DECLARE c_moncurseur CURSOR FOR SELECT idvendeur, SUM(totalcde) AS tot FROM commande GROUP BY idvendeur ; v_nbmeublesvendu INTEGER ; ... BEGIN FOR v_uneligne IN c_moncurseur LOOP

Séquence 5 La programmation du SGBDR

Page 157

IF (v_uneligne.tot >= 7500) THEN SELECT SUM(qtecde) INTO v_nbmeublesvendu FROM commande NATURAL JOIN lignecommande WHERE idvendeur = v_uneligne.idvendeur GROUP BY idvendeur ; ... END IF ; END LOOP ; END;

Dans cet extrait, on peut voir que la variable d’accueil "v_uneligne" est automatiquement déclarée, mais n’existe qu’au sein de la structure "FOR". On peut également voir que la variable d’accueil est une structure qui correspond à celle de la ligne qu’elle va recevoir. Pour accéder à ses propriétés, il suffit d’utiliser la notation pointée comme pour "v_uneligne.idvendeur".

8 2955 TG PA 00

Exercice 4 1. Créer les fonctions suivantes en SQL/PSM et en utilisant des curseurs : –– nbmeublespourunvendeur() : fonction qui retourne le nombre de meubles qu’a vendu un vendeur dont l’idVendeur a été passé en paramètre ; –– carealisepourunvendeur() : fonction qui retourne le CA réalisé par un vendeur dont l’idVendeur a été passé en paramètre. 2. Programmer le dernier exemple du cours (recherche des vendeurs ayant vendu au moins 500 meubles pour un CA total d’au moins 7 500 €) à l’aide des fonctions que vous venez de créer.

9. La gestion des exceptions Une exception est créée lorsqu’une erreur survient. Dans un fonctionnement standard, lorsqu’une exception se produit, l’exécution du programme s’interrompt et l’exception est traitée : • soit ces exceptions sont gérées au sein du programme par un gestionnaire ("handler" en anglais) et le programme garde la main ; • soit ces exceptions ne sont pas gérées et le programme s’interrompt.

Séquence 5 La programmation du SGBDR

Page 158

Comme vous l’avez vu en langage orienté objet (Java, C++, C#…), à chaque fois que l’on écrit un code susceptible de provoquer une erreur (accès à un ordinateur distant non connecté, ou sur un SGBDR, une requête sans résultat, une division par zéro…) il faut protéger l’intégrité du programme en utilisant un gestionnaire qui va intercepter l’erreur et voir si un traitement est associé à cette erreur. Nous avons vu au point précédent comment déclarer un gestionnaire et le configurer pour qu’il réalise une action lorsque l’erreur en question survient. • Reprenons notre gestionnaire ("HANDLER") qui a pour mission d’intercepter les erreurs de type "NOT FOUND" et qui, sans interrompre le programme ("CONTINUE") doit affecter une valeur ("TRUE") à une variable ("v_curseurvide") : DECLARE v_curseurvide BOOLEAN DEFAULT FALSE ; CONTINUE HANDLER FOR NOT FOUND SET v_curseurvide := TRUE ;

• En PL/pgSQL sous PostgreSQL la gestion des exceptions se fait à l’aide d’un bloc supplémentaire à l’intérieur du bloc exécutable. Cette gestion se fait à l’aide des clauses "EXCEPTION … WHEN … THEN" : BEGIN ... EXCEPTION WHEN NO_DATA_FOUND THEN action1... ; WHEN DIVISION_BY_ZERO THEN action2... ; ... END ;

8 2955 TG PA 00

Chaque SGBDR possède sa propre liste d’erreurs qu’il ne faut pas hésiter à consulter dès que l’on souhaite mettre en place une réelle gestion des exceptions.

Débogage et journalisation Il est toujours intéressant de pouvoir produire des messages en cours d’exécution. Pendant la phase de développement pour déboguer les programmes et ensuite en production pour pouvoir retrouver les actions réalisées ou les erreurs générées. • Par exemple si en cours d’exécution on veut produire un message qui indique que le traitement "1" a réussi : ... SELECT ‘Le traitement 1 a réussi !’ ; ...

• En PL/pgSQL la génération de messages se fait avec l’instruction "RAISE NOTICE" : ... RAISE NOTICE ‘Le traitement 1 a réussi !’ ; ...

Exercice 5 Extrait du Cas CAPDC (Métropole 2008) La Chambre d’Agriculture du Pas-de-Calais (CAPDC) assure des missions d’accompagnement pour le développement de l’agriculture dans son département. Elle propose aux agriculteurs des prestations diverses : • analyses de projets d’installation, de diversification... ; • actions de sensibilisation et de promotion autour des métiers de l’agriculture ; • formation et conseils sur la prise en compte de préoccupations environnementales (gestion des milieux naturels, élimination des déchets...).

Séquence 5 La programmation du SGBDR

Page 159

Au titre de la protection des milieux naturels, les agriculteurs sont tenus de rendre compte des quantités d’engrais et de traitements (pesticides, désherbants...) apportés à leurs cultures. Ce contrôle conditionne les aides accordées aux agriculteurs dans le cadre de la politique agricole commune (PAC). Les agriculteurs doivent donc remplir régulièrement un cahier d’épandage pour les engrais et un registre phytosanitaire pour les traitements. Le service informatique de la Chambre d’Agriculture a sollicité la SSII Sigeto pour collaborer au projet AIM (Agriculture Information Maîtrisée) dont l’objectif est de faciliter la gestion des échanges entre les agriculteurs et les autres acteurs du monde agricole. Le logiciel AIM permettra de saisir, stocker, consulter et échanger des données relatives à l’exploitation agricole et aux activités de culture et d’élevage. Il constituera une aide à la déclaration, à la traçabilité et à la gestion technico-économique de l’exploitation.

8 2955 TG PA 00

Les Traitements Phytosanitaires Les exploitants agricoles sont souvent amenés à épandre sur les cultures des produits afin de lutter contre les maladies éventuelles des espèces cultivées. On appelle cette opération un traitement phytosanitaire car il utilise des produits pesticides (organiques ou chimiques). Un traitement phytosanitaire peut concerner une semence (il est alors mélangé à la semence avant le semis) ou une culture en champ (il est alors appliqué en une ou plusieurs pulvérisations sur cette culture). À cet effet, les exploitants sont tenus de remplir un registre phytosanitaire, fourni par la Chambre d’Agriculture, enregistrant les différents épandages. Ce registre est actuellement un document papier. Il est envisagé de proposer aux agriculteurs qui le désirent une application spécifique. Cette application, actuellement en phase de test, permettra les saisies des informations par les agriculteurs eux-mêmes (via Internet) ainsi qu’un traitement centralisé de ces informations (contrôles, statistiques). La base de données utilisée pour l’application est présentée en annexe 3.

Séquence 5 La programmation du SGBDR

Page 160

Une parcelle peut faire l’objet de traitements ; si le traitement est de type "semence", il est unique car le produit est mélangé au semis. En revanche, si le traitement est "en champ", celui-ci est constitué d’une ou plusieurs pulvérisations. Le champ typeTraitement indique la nature de ce traitement. Le champ dosageTraitementSemence enregistre le dosage (quantité par unité de surface) pour le traitement "en champ semence" ; le champ dosage de la table Pulvérisation précise le dosage de chaque pulvérisation. Remarque Le SGBDR utilisé dispose de la fonction dateDiff(uneDateDebut, uneDateFin) qui renvoie en nombre de jours le résultat de la soustraction de la date uneDateDebut à la date uneDateFin. Exemple : dateDiff(‘15-03-2008’, ‘25-04-2008’) retourne la valeur 41. Une nouvelle législation entraînant l’interdiction de pulvérisations dans les 30 jours qui précèdent la récolte, la Chambre d’Agriculture souhaite adresser un courriel d’information à l’ensemble des exploitants qui possèdent des parcelles ayant fait l’objet de pulvérisations moins de 30 jours avant la date de récolte prévue. Il est prévu de sécuriser l’application en évitant les saisies indésirables remettant en cause les règles de gestion métier. C’est ainsi que des déclencheurs (triggers) assureront l’intégrité des données.

8 2955 TG PA 00

Un déclencheur a été écrit : CREATE TRIGGER trg_insert_pulverisation BEFORE INSERT ON Pulverisation

NEW désigne ici la ligne de la table Pulverisation en cours d’insertion.

FOR EACH ROW DECLARE typeTr CHAR(1) ;

/* déclaration de la variable locale typeTr */

SELECT typeTraitement INTO typeTr FROM traitement WHERE traitement.id = NEW.idTraitement IF typeTr = ‘s’ BEGIN

RAISERROR /* génère une erreur */

END

Travail à faire 1. Indiquer la règle de gestion prise en charge par le déclencheur. 2. É  crire le déclencheur qui permet de respecter la règle de gestion suivante : "pour une parcelle, il ne peut y avoir qu’un seul traitement en semence puisque le produit phytosanitaire est mélangé au semis".

Séquence 5

Annexe 3 : Extrait du schéma relationnel de la base de données "TraitementPhyto" PRODUITPHYTOSANITAIRE(id, libelle) Clé primaire : id

La programmation du SGBDR

Page 161

EXPLOITATION(id, nomExploitant, melExploitant) Clé primaire : id PARCELLE(id, dateSemis, dateRecoltePrevue, surface, idExploitation,idEspeceCultivee) Clé primaire : id Clé étrangère : idExploitation en référence à id de EXPLOITATION Clé étrangère : idEspeceCultivee en référence à id de ESPECECULTIVEE TRAITEMENT(id, typeTraitement, dosageTraitementSemence, idParcelle, idProduitPhytosanitaire) Clé primaire : id Clé étrangère : idParcelle en référence à id de PARCELLE Clé étrangère : idProduitPhytosanitaire en référence à id de PRODUITPHYTOSANITAIRE PULVERISATION(id, datePulverisation, dosage, idTraitement) Clé primaire : id Clé étrangère : idTraitement en référence à id de TRAITEMENT ESPECECULTIVEE(id, libelle, type) Clé primaire : id

8 2955 TG PA 00

Dans la relation TRAITEMENT : • Si le traitement est en semence (produit mélangé au semis), le champ typeTraitement prend la valeur ‘s’ et le champ dosageTraitementSemence prendra une valeur. • Si le traitement est en champ (plusieurs pulvérisations), le champ typeTraitement prend la valeur ‘c’ et le champ dosageTraitementSemence prendra la valeur nulle. Dans ce cas seulement, plusieurs occurrences de la relation PULVERISATION pourront être associées à ce traitement.

Exercice 6 Extrait du Cas THALI (Nouvelle Calédonie 2008) THALI est un centre de thalassothérapie situé au bord de l’Océan Atlantique. Il accueille des clients en cure toute l’année et dispose d’un hôtel pour l’hébergement des curistes qui le souhaitent. THALI a choisi de fermer ses portes pendant trois mois pour rénover entièrement ses locaux, acquérir de nouveaux équipements et refondre son système d’information. Le site web de THALI permet actuellement de commander en ligne les produits sélectionnés par le centre de thalassothérapie pour leurs vertus bienfaitrices. Séquence 5 La programmation du SGBDR

Page 162

Vous disposez de l’extrait suivant du schéma relationnel de la base de données recensant les produits commercialisés en ligne : CATEGORIE(code, libellé) code : clé primaire Remarque : Les libellés des catégories sont Visage, Mains, Corps, Cheveux, Silhouette et Homme. GAMME(codeCatég, numéro, libellé) codeCatég, numéro : clé primaire codeCatég : clé étrangère en référence à code de la relation CATEGORIE Exemples de libellés de gamme : Hydratant, Maquillage pour le visage Hydratant et Anti-taches pour les mains. PRODUIT(code, désignation, descriptifComposition, descriptifProduit, conditionnement, contenance, nomFichierImage, conditionUtilisation, codeCatég, numéroGamme) code : clé primaire codeCatég, numéroGamme : clé étrangère en référence à codeCatég, numéro de la relation GAMME. Remarques : • Le code est alphanumérique (exemple : A044). • Le descriptif de la composition précise, sous forme d’une chaîne de caractères, les ingrédients essentiels avec les pourcentages. • Le conditionnement peut être : flacon, pot, tube, etc. TARIFPRODUIT(codeProduit, dateDébutApplicPrix, dateFinApplicPrix, prix) codeProduit, dateDébutApplicPrix : clé primaire codeProduit : clé étrangère en référence à code de la relation PRODUIT.

8 2955 TG PA 00

Remarque La date de fin d’application n’est renseignée que lorsqu’une nouvelle ligne est créée dans la table TARIFPRODUIT pour le produit en question à moins qu’il s’agisse d’une promotion ; dans ce dernier cas, la date de fin d’application est renseignée lors de la création de la ligne. Le centre THALI souhaite que, lors d’un changement de tarif, la création d’une ligne dans la table TARIFPRODUIT entraîne la mise à jour de la date de fin d’application du tarif actuel (si bien sûr, le produit était déjà commercialisé). Dans le cas où la date de fin d’application était déjà renseignée, aucune mise à jour ne doit être effectuée.

Travail à faire Expliquer clairement le mécanisme à mettre en place. Le code correspondant n’est pas à écrire.

Exercice 7 Extrait du Cas TELINOS (Nouvelle Calédonie 2006) TELINOS est une société de diffusion de chaînes de télévision sur le câble assurant l’installation chez ses clients. Cette société propose deux prestations distinctes : La vente d’abonnements aux bouquets existants

Séquence 5

Un bouquet est un ensemble de chaînes de télévision. TPS et CanalSatellite sont des bouquets proposés par des sociétés commerciales appelées opérateurs (CanalSatellite est par exemple proposé par le groupe CanalPlus). Pour cette prestation, TELINOS prend en charge la totalité du processus d’abonnement et d’installation chez le client.

La programmation du SGBDR

Page 163

La vente de son offre "TELINOS à la carte" "TELINOS à la carte" permet au client de choisir les chaînes qu’il recevra parmi l’ensemble des chaînes disponibles sur le marché, qu’elles soient publiques ou privées, propres ou non à un bouquet existant. L’objectif est de proposer une solution souple permettant à chaque client de composer sa propre carte de chaînes. Ainsi, actuellement un abonné TPS ne peut recevoir "Jimmy" ou "13e rue" qui sont des chaînes propres au bouquet CanalSatellite ; inversement, "Sérieclub" n’est accessible qu’avec un abonnement TPS. Un abonnement "TELINOS à la carte" permettra de recevoir "Sérieclub" et "13e rue", si le client le souhaite. La société TELINOS a ouvert un certain nombre d’agences dans les principales villes de France. Ces agences permettent d’avoir un contact direct avec les clients et regroupent des commerciaux qui se rendent chez les clients potentiels (prospects) dès qu’un nouveau secteur est précâblé. Au sein de la ville d’A., une application a été développée pour suivre les visites effectuées par les commerciaux en direction des prospects. Le schéma relationnel sur lequel est basée cette application vous est fourni ci-dessous : PROSPECT (code, nom, prenom, adresse, codeCategorieSP, codeSecteur) code : clé primaire codeCategorieSP : clé étrangère en référence à code de CATEGORIESP codeSecteur : clé étrangère en référence à code de SECTEUR

8 2955 TG PA 00

SECTEUR (code, libelle) code : clé primaire CATEGORIESP (code, libelle) code : clé primaire COMMERCIAL (code, nom, prenom, telephone, mel, dateEmbauche) code : clé primaire AFFECTE (codeCommercial, dateDebut, codeSecteur, dureeAffectation) codeCommercial, dateDebut : clé primaire codeCommercial : clé étrangère en référence à code de COMMERCIAL codeSecteur : clé étrangère en référence à code de SECTEUR VISITE

Séquence 5 La programmation du SGBDR

(codeProspect, date, codeCommercial, resultat, commentaire) codeProspect, date : clé primaire codeProspect : clé étrangère en référence à code de PROSPECT codeCommercial : clé étrangère en référence à code de COMMERCIAL

Remarques • La table PROSPECT enregistre les différents clients potentiels. Ces clients sont répartis, par secteur selon leur adresse. Un secteur peut regrouper jusqu’à 500 prospects. • La table SECTEUR enregistre les différents secteurs géographiques. • La table CATEGORIESP enregistre les différentes catégories socioprofessionnelles (CSP) auxquelles peuvent appartenir les prospects  : étudiant, artisan, ouvrier, employé... • Dans la table AFFECTE, la durée d’affectation d’un commercial dans un secteur est exprimée en jours. • La table VISITE permet de connaître les résultats des visites chez les prospects.

Page 164

On donne ci-après le corps du déclencheur qui a été défini sur la table VISITE lors de l’insertion d’une ligne dans cette table. /* déclaration des variables locales au déclencheur */

DECLARE numrows INTEGER; :new désigne ici la ligne de la table /* instructions du déclencheur */ BEGIN VISITE en cours d’insertion SELECT count(*) into numrows FROM AFFECTE A, PROSPECT P raise_application_error() est une foncWHERE A.codeCommercial = tion intégrée au SGBDR utilisé qui :new.codeCommercial AND P.code = :new.codeProspect permet d’une part de générer une AND A.codeSecteur = P.codeSecteur erreur de numéro -10000 accompagné IF (numrows = 0) d’un message d’erreur et d’autre part THEN raise_application_error (-10000, ‘Erreur’) d’annuler la mise à jour courante, en l’occurrence ici l’insertion d’une ligne END IF ; END dans la table

8 2955 TG PA 00

Travail à faire 1. Indiquer le rôle du déclencheur et proposer un libellé explicite de message d’erreur en remplacement du libellé ‘Erreur’ figurant dans l’appel de la fonction raise_application_error. On désire s’assurer également que la date de la visite du commercial soit compatible avec sa période d’affectation à un secteur. On dispose dans le SGBDR de la fonction dateAdd (uneDate, unNbJours) qui renvoie la date postérieure de unNbjours au paramètre uneDate.

Travail à faire 2. Apporter les modifications nécessaires à la requête SELECT présente dans le déclencheur afin de prendre en compte la contrainte concernant la date de la visite du commercial.

Exercice 8 Extrait du Cas EDF (Métropole 2007) L’activité du centre EDF de Douvres est essentiellement axée autour des branchements électriques dans le département du Calvados. Le centre sous-traite une partie de son activité en confiant à des entreprises extérieures la réalisation des branchements chez les clients. Le traitement d’un branchement se déroule en plusieurs étapes : • l’enregistrement de la demande de branchement d’un client et la validation des informations collectées ; • l’élaboration du devis correspondant à la demande ; • la gestion des plannings et la communication des dates et lieux des rendez-vous aux sous-traitants ; • la réalisation des branchements par les sous-traitants ; • l’enquête de qualité afin de mesurer le degré de satisfaction des clients ainsi que la qualité du travail réalisé par les sous-traitants et par le centre de Douvres.

Séquence 5 La programmation du SGBDR

Page 165

Pour organiser les branchements, le département est découpé en ZEI (zones élémentaires d’intervention). Une ZEI correspond à un secteur autour d’une ville principale. On planifie chaque opération à réaliser en tenant compte d’une durée théorique appelée poids. Pour effectuer les installations, le centre EDF de Douvres organise le planning des interventions des sous-traitants. Chaque contrat de sous-traitant couvre un certain nombre de ZEI et indique les jours d’intervention possibles. Le centre de Douvres dépend du centre informatique de Mulhouse qui héberge l’application de gestion du planning. L’exploitation des données étant trop complexe, le responsable de Douvres a décidé d’installer une nouvelle application utilisant une base de données locale. Un extrait du schéma de cette base de données est présenté en annexe 4. À la demande du responsable, la secrétaire établit l’état des disponibilités pour une journée et un sous-traitant donnés. Ce document informe sur la charge restant à attribuer au sous-traitant le matin et l’après-midi de la journée demandée, pour chacun des contrats intégrant cette journée dans les disponibilités du sous-traitant.

8 2955 TG PA 00

Par exemple, le récapitulatif des disponibilités du sous-traitant STEN pour le 13 Juillet 2007 prend la forme suivante :

DATE : 13/07/2007 Nom du sous-traitant : STEN Contrat  n° : 3 Charge restante MAT 240

Charge restante APM 240

Contrat  n° : 4 Charge restante MAT

Charge restante APM 0 120 Séquence 5 La programmation du SGBDR

Page 166

Pour automatiser l‘obtention de cet état, le responsable a écrit le début de la procédure d’édition : PROCÉDURE editEtatSousTraitant (nomSaisi : chaîne, dateSaisie : date) Variables

/* déclaration du curseur */



Curs_SousTraitant curseur pour



SELECT C.numero, chargeMAT, chargeAPM FROM PLANNING P, CONTRAT C, SOUS_TRAITANT S WHERE C.codeSousTraitant = S.code AND P.numeroContrat = C.numero AND dateJournée = :dateSaisie AND nom = :nomSaisi ORDER BY 1

…

Travail à faire Compléter sur la copie, la procédure editEtatSousTraitant qui permet d’obtenir l’état des disponibilités. La mise en page n’est pas à gérer. On supposera qu’il y a toujours au moins un contrat concerné par la date et le soustraitant donnés.

8 2955 TG PA 00

Annexe 4 : Extrait du schéma relationnel de la base "Gestion des rendez-vous" Les tables décrites ci-dessous ne permettent pas de répondre à tous les besoins de l’application, mais elles suffisent pour répondre aux questions posées dans le dossier concerné. SOUS_TRAITANT (code, nom) code : clé primaire

Représente tous les sous-traitants.

CONTRAT (numero, codeSousTraitant, nbTotRDVPris) numero : clé primaire codeSousTraitant : clé étrangère en référence à code de SOUS_TRAITANT Remarque • nbTotRDVPris : nombre total de rendez-vous pour l’année en cours Représente tous les contrats passés avec les sous-traitants pour l’année en cours. PLANNING (dateJournee, numeroContrat, chargeMAT, chargeAPM) dateJournée, numeroContrat : clé primaire numeroContrat : clé étrangère en référence à numero de CONTRAT Remarques • chargeMAT correspond à la charge de travail affectée le matin ; elle est initialisée à zéro au moment de la création et ne peut dépasser 240 minutes. • chargeAPM correspond à la charge de travail affectée l’après-midi ; elle est initialisée à zéro au moment de la création et ne peut dépasser 240 minutes.

Séquence 5 La programmation du SGBDR

Page 167

Représente toutes les journées d’intervention planifiées à l’avance dans le cadre des contrats passés pour l’année en cours. Exemple : Si le mardi et le mercredi sont les jours d’intervention possibles dans le cadre du contrat N, la table PLANNING contient, pour ce contrat, autant de lignes que de mardis et de mercredis dans l’année en cours. AFFECTER (codeZEI, numeroContrat) codeZEI, numeroContrat : clé primaire numeroContrat : clé étrangère en référence à numero de CONTRAT Représente toutes les affectations de ZEI à chaque contrat de l’année en cours.

TP 2 Vous pouvez faire le TP2 dans le fascicule de travaux pratiques.

8 2955 TG PA 00

Synthèse

DECLARE : Permet de débuter un bloc de déclaration BEGIN : Débute un bloc exécutable END : Termine un bloc exécutable -- : Met une ligne en commentaire /* : Marque le début d’un bloc de commentaires */ : Ferme un bloc de commentaires SET mavar := uneval : Affectation de la valeur "uneval" à la variable "mavar" CREATE PROCEDURE uneproc : Création d’une procédure stockée du nom de "uneproc" CALL uneproc() : Appel de la procédure "uneproc"

Séquence 5 La programmation du SGBDR

Page 168

8 2955 TG PA 00

CREATE FUNCTION unefonc  : Création d’une fonction stockée du nom de "unefonc" –– RETURNS untype : Permet d’indiquer que la valeur de retour de la fonction sera du type "untype". syntaxe : CREATE FUNCTION unefonc RETURNS untype –– RETURN : Permet de retourner une valeur du type indiqué par la clause "RETURNS". syntaxe : CREATE FUNCTION unefonc RETURNS untype BEGIN … RETURN uneval END ; CREATE PROCEDURE uneproc(IN var1 untype,INOUT var2 untype,OUT var3 untyp) : Création d’une procédure stockée du nom de "uneproc" qui reçoit trois paramètres : –– IN : qui signifie que le mode de passage du paramètre est "en entrée" ; –– INOUT  : qui signifie que le mode de passage du paramètre est "en entrée-sortie" ; –– OUT : qui signifie que le mode de passage du paramètre est "en sortie". CREATE FUNCTION unefonc(IN var1 untype,INOUT var2 untype,OUT var3 untype) : Création d’une fonction stockée du nom de "unefonc" qui reçoit trois paramètres : –– IN, INOUT, OUT : même explication que pour la procédure stockée. CREATE TRIGGER : Création d’un déclencheur –– BEFORE | AFTER : Signifie que le déclencheur agira avant ou après l’évènement qui l’a déclenché. –– INSERT | UPDATE | DELETE : Spécifie quel est le type d’évènement qui va activer le déclencheur. –– ON table : Permet de préciser que le déclencheur s’activera si l’opération mentionnée juste avant concerne la table "table".

–– FOR EACH ROW : Spécifie que les actions contenues dans le déclencheur s’exécuteront une fois pour chaque enregistrement concerné par l’évènement déclencheur. syntaxe : CREATE TRIGGER BEFORE | AFTER INSERT | UPDATE | DELETE ON table FOR EACH ROW BEGIN … END ; OLD | NEW : Alias de ligne qui permettent dans le cadre d’un déclencheur de récupérer l’"ancien" état d’une ligne et le "nouveau" DECLARE uncurs CURSOR FOR unereq : Déclare un curseur du nom de "uncurs" qui contiendra le résultat de la requête "unereq" OPEN uncurs : Ouvre le curseur "uncurs" FETCH uncurs INTO var1, var2, …, varN : Lit le contenu de la ligne en cours du curseur "uncurs", se positionne sur la ligne suivante et place le contenu de la ligne lue dans les variables "var1" à "varN" CLOSE uncurs : Ferme le curseur "uncurs" DECLARE CONTINUE HANDLER FOR "uneexception" : Déclare un gestionnaire chargé de continuer l’exécution d’un programme après qu’une exception de type "uneexception" ait été levée syntaxe : DECLARE CONTINUE HANDLER FOR uneexception instructions… ;

Séquence 5 La programmation du SGBDR

Page 169

8 2955 TG PA 00

Séquence 6

Autocorrection Vous trouverez ici la correction de tous les exercices du fascicule. Les exercices étant numérotés par séquence, vous les retrouverez classés par séquence.  Contenu 1. Le modèle relationnel.......................................................................................... 172 2. Le modèle conceptuel de données...................................................................... 174 3. Extensions sous Merise/2...................................................................................... 200 4. MCD ou Diagramme de classes ?......................................................................... 232 5. La programmation du SGBDR.............................................................................. 238

Page 171

8 2955 TG PA 00

8 2955 TG PA 00

1. Le modèle relationnel  Exercice 1 DF

élém.

directe

X

X

X

nomClient à adrClient idClient à adrClient idCommande, idClient à qteCommandée idCommande, idArticle à prixArticle

X

X

idCommande, idArticle à qteCommandée

X

X

X

idCommande à dateCommande

X

X

X

idCommande à nomClient

X

X

idCommande à nomArticle nomClient à adrClient Ce n’est pas une DF car dans le cas d’homonymes, 2 clients peuvent avoir le même nom et habiter à des endroits différents. idClient à adrClient

Séquence 6 Autocorrection

Page 172

C’est bien une DF puisque qu’un idClient identifie un client unique qui donc possède une adresse. La DF est élémentaire puisque de toute façon il n’y a qu’un attribut à gauche (donc on a bien un nombre minimum d’attributs pour obtenir celui de droite). La DF est directe puisqu’il n’y a pas d’intermédiaires : un idClient donne directement l’adresse du client. idCommande, idClient à qteCommandée On imagine une commande avec plusieurs articles dans des quantités différentes. Pour obtenir la qteCommandée, l’idClient ne sert vraiment à rien et l’idCommande n’est pas suffisant car il peut y avoir plusieurs articles. Donc ce n’est pas une DF. idCommande, idArticle à prixArticle l’idArticle identifie de façon unique un article, donc le prix est naturellement accessible. C’est une DF mais elle n’est pas élémentaire car l’idCommande ne sert à rien. En revanche elle est directe car l’idArticle donne directement le prix. idCommande, idArticle à QteCommandée C’est une DF élémentaire et directe : pour obtenir une quantité commandée, on a besoin de connaître la commande concernée mais aussi, dans cette commande, l’article concerné. Il y a donc le minimum d’attributs nécessaires et il n’y a pas d’intermédiaire. idCommande à dateCommande C’est une DF élémentaire et directe car une commande n’est passée qu’à une seule date et il n’y a aucun intermédiaire nécessaire. idCommande à nomClient C’est une DF car une commande ne concerne qu’un seul client. Elle est élémentaire car il y a bien un nombre d’attribut minimum (puisqu’il n'y en a qu’un, la question ne se pose même pas). En revanche cette DF n’est pas directe car il existe bien un attribut intermédiaire : l’idCommande peut nous donner directement l’idClient qui lui, va nous permettre d’accéder à toutes les informations du client, entre autres à son nom. idCommande à nomArticle Nous avons vu plus haut qu’une commande peut contenir plusieurs articles. Donc ce n’est pas une DF.

8 2955 TG PA 00

Exercice 2 Voici la solution la plus optimale : Etudiant (idEtudiant, nomEtudiant) Classe (idClasse, nomClasse) Matière (idMatière, nomMatière) Matière_Classe (idMatière#, idClasse#, coefMatière) Inscription (idEtudiant#, annéeInscription, idClasse#)

Les relations Etudiant, Classe et Matière Pour ces 3 relations, il n’y a pas de difficulté particulière. La relation Matière_Classe Pour Matière_Classe, le but était de trouver comment accéder à coefMatière : le sujet dit clairement que le coefficient dépend de 2 informations : la classe et la matière. Donc il est nécessaire d’avoir une clé primaire constituée des 2 clés primaires de Classe et Matière pour accéder au coefficient. Remarquez bien que idMatière est clé primaire et étrangère à la fois. Pourquoi ? Vous avez compris pourquoi idMatière est clé primaire. idMatière est aussi clé étrangère car il se trouve que idMatière est aussi clé primaire dans une autre relation. C’est la définition d’une clé étrangère : attribut qui est clé primaire dans une autre relation. Du coup, à partir de la relation Matière_Classe, il sera possible aussi d’accéder à la matière correspondante dans Matière et récupérer les informations voulues. Suivant la même logique, idClasse est aussi clé primaire et étrangère à la fois. La relation Inscription

Séquence 6

Pour l’année d’inscription, c’est nettement plus complexe. Pourquoi avoir fait une clé primaire constituée de idEtudiant et de annéeInscription ? Parce que, la clé primaire devant être unique, un étudiant + une année d’inscription ne peut représenter qu’une inscription précise. C’est exactement ce que l’on veut. À partir de cette clé primaire, on obtient la classe d’inscription. Comme il existe déjà une relation Classe, il suffit de mettre une clé étrangère pour accéder à la classe correspondante. Remarquez que idEtudiant est clé primaire et étrangère à la fois (comme idMatière et idClasse dans la relation Matière_Classe). En revanche, remarquez que annéeInscription est seulement clé primaire. C’est normal puisque annéeInscription n’est pas clé primaire ailleurs. Mais pourquoi ne pas avoir mis tout simplement idEtudiant et idClasse en clé primaire et annéeInscription en attribut simple ? Parce qu’un étudiant a le droit, d’après le sujet, de s’inscrire plusieurs fois dans la même classe, à des années différentes. La clé devant être unique, il n’est donc pas possible de mettre idEtudiant + idClasse en clé primaire.

Autocorrection

Page 173

Les noms des relations Les noms des relations sont libres. Faites juste en sorte de donner des noms qui soient le plus représentatifs possibles. La nouvelle notation Puisque vous devez savoir lire les 2 notations, voici la correction avec la nouvelle notation.

8 2955 TG PA 00

Etudiant (idEtudiant, nomEtudiant) idEtudiant : clé primaire Classe (idClasse, nomClasse) idClasse : clé primaire Matière (idMatière, nomMatière) idMatière : clé primaire Matière_Classe (idMatière, idClasse, coefMatière) idMatière, idClasse : clé primaire idMatière : clé étrangère en référence à idMatière de Matière idClasse : clé étrangère en référence à idClasse de Classe Inscription (idEtudiant, annéeInscription, idClasse) idEtudiant, annéeInscription : clé primaire idEtudiant : clé étrangère en réf. à idEtudiant de Etudiant idClasse : clé étrangère en référence à idClasse de Classe

Vous vous posez peut-être la question : pourquoi 2 notations ? La nouvelle notation est normalisée et nettement plus puissante. Par exemple, une clé étrangère n’est pas obligée d’avoir le même nom que la clé primaire correspondante. Vous aurez l’occasion de voir par la suite que cette notation est parfois indispensable.

2. Le modèle conceptuel de données Exercice 1 Séquence 6 Autocorrection

Page 174

Ce premier exercice représente l’application directe des notions qui viennent d’être vues en cours. Chaque relation qui ne comporte qu’une clé primaire se transforme en entité. Chaque relation qui comporte une clé primaire composée de plusieurs attributs se transforme en association, les liens directs permettant de récupérer les identifiants. Chaque clé étrangère se transforme en CIF.

Exercice 2 Ce schéma a été réalisé sous Win’Design. Vous remarquez que les règles de schématisations sont proches de celles que je vous ai présentées. La différence se situe au niveau de l’héritage avec la présence de ce triangle qui rassemble les liens provenant des sous-types pour ne faire qu’un lien allant vers le sur-type. Sur papier, vous pouvez choisir la notation que vous préférez.

8 2955 TG PA 00

Vous avez remarqué que dans l’écriture des relations, avec la nouvelle notation, on a pu donner des noms très parlants aux clés étrangères puisque de toute façon le lien est clairement défini avec la clé primaire correspondante.

Exercice 3

Séquence 6

Les 2 schémas proposés sont directement issus du cours, dans les pages précédentes, avec juste un petit ajout.

Autocorrection

1er schéma :

Page 175

CHAUFFEUR (idChauffeur, nom) idChauffeur : clé primaire BUS (idBus, dateAchat) idBus : clé primaire LIGNE (idLigne, libellé) idLigne : clé primaire TRAJET (idLigne, date, heureDeb, idChauffeur, idBus) idLigne, date, heureDeb : clé primaire idLigne : clé étrangère en réf. à idLigne de LIGNE idChauffeur : clé étrangère en réf. à idChauffeur de CHAUFFEUR idBus : clé étrangère en réf. à idBus de BUS

Remarquez que HORAIRE et DATE, entités temporelles, n’existent plus dans le schéma relationnel. Remarquez aussi, dans la relation TRAJET, que du coup seul idLigne est clé primaire et étrangère à la fois (date et heureDeb sont simplement clés primaires). Imaginons l’entité BUS ne contenant qu’un identifiant et pas d’attribut simple. Chaque bus est donc repéré par un numéro, mais on n’a besoin d’aucune autre information. Attention, dans ce cas on aurait affaire à une entité qui se traduit tout de même en relation au niveau du schéma relationnel car on a besoin de connaître la liste de nos bus. 2e schéma : HOTEL (idHotel, nom, adresse) idHotel : clé primaire CLIENT (idClient, nom) idClient : clé primaire

8 2955 TG PA 00

CHAMBRE (idHotel, numChambre) idHotel, numChambre : clé primaire idHotel : clé étrangère en réf. à idHotel de HOTEL FACTURE (idHotel, numChambre, dateDebutLoc, dateFinLoc, idClient) idHotel, numChambre, dateDebutLoc : clé primaire idHotel : clé étrangère en réf. à idHotel de HOTEL idClient : clé étrangère en réf. à idClient de CLIENT

L’entité DATE a disparu, ce qui est normal. L’entité NUMCHAMBRE a disparu aussi : il n’y a aucun intérêt de garder une liste de numéros de chambres entre tous les hôtels. En revanche ce n’est pas pour rien qu’il y a l’association CHAMBRE pour connaître la liste des chambres par hôtel. Cette association s’est traduite en relation, comme toute association, même vide.

Exercice 4

Séquence 6 Autocorrection

Page 176

JOUET (idJouet, nom, idCategorie) idJouet : clé primaire idCategorie : clé étrangère en réf. à idCategorie de CATEGORIE CATEGORIE (idCategorie, libellé) idCategorie : clé primaire ENFANT (idEnfant, nom, age, adresse) idEnfant : clé primaire COMMANDE (idEnfant, idJouet) idEnfant, idJouet : clé primaire idEnfant : clé étrangère en réf. à idEnfant de ENFANT idJouet : clé étrangère en réf. à idJouet de JOUET

Règles de gestion Un jouet n’est que d’une catégorie. Une catégorie peut concerner 0 à plusieurs jouets. Un jouet peut être commandé par 0 à plusieurs enfants. Un enfant peut commander 1 à plusieurs jouets (si vous avez mis la cardinalité à 0, ce n’est pas faux : cela traduit que vous enregistrez les enfants avant qu’ils aient passé commande).

8 2955 TG PA 00

L’auteur de ces relations hésitait entre l’attribut "age" et l’attribut "dateDeNaissance" dans l’entité "ENFANT". Dire s’il a fait le bon choix, en justifiant la réponse. L’attribut dateDeNaissance est le meilleur choix car il évite la réactualisation des informations chaque année. L’âge est facile à calculer à partir de la date de naissance. 2e version :

Ne soyez pas étonné par les cardinalités 0,n autour de ATELIER : cela traduit juste le fait que, au moment de la création d’un atelier, l’affectation des lutins et la désignation des jouets qui le concernent ne va peut-être pas se faire immédiatement. Si vous avez mis 1,n c’est juste aussi.

Séquence 6

3 version :

Autocorrection

e

Page 177

La CIF entre JOUET et CATEGORIE se transforme en association normale puisqu’un jouet peut être classé dans plusieurs catégories. Une enfant peut commander plusieurs exemplaires du même jouet : il suffit de mettre la quantité commandée dans l’association (ce sera bien la quantité de ce jouet pour cet enfant). Un enfant doit préciser l’ordre d’importance des jouets qu’il commande. Encore une fois, il suffit d’ajouter un attribut dans l’association : un numéro d’ordre permettra de connaître l’ordre d’importance de ce jouet pour cet enfant. Ceux qui ont transformé COMMANDE en entité en mettant ordre en identifiant relatif et en faisant un lien identifiant sur ENFANT ont juste aussi : il fallait alors aussi faire une CIF qui va de COMMANDE vers JOUET.

8 2955 TG PA 00

Exercice 5 a) Dessiner le SCD à l’origine de ces relations (en version Merise/2).

Pour représenter FICHE_DOSSIER, vous auriez pu faire une association entre DOSSIER et une entité numéro pour récupérer numFiche au niveau des identifiants de l’association. La représentation utilisée ici est celle respectant les règles de Merise/2 : l’identifiant de FICHE_DOSSIER est la concaténation entre numFiche et idDossier. b) Comment appelle-t-on le lien qui unit FICHE_DOSSIER à DOSSIER ?

Autocorrection

C’est un lien identifiant : il peut être représenté, comme ici, avec un (R), ou aussi avec (1,1). Le lien identifiant indique que FICHE_DOSSIER est non seulement identifié par numFiche, mais aussi par l’identifiant de DOSSIER. numFiche est appelé "identifiant relatif" et FICHE_DOSSIER est une entité faible car elle dépend d’une autre entité. Elle n’a pas de vie propre. En effet, les fiches sont forcément rattachées à un dossier.

Page 178

c) Pourquoi numFiche n’est pas aussi en clé étrangère dans la relation FICHE_DOSSIER ?

Séquence 6

Parce que numFiche n’a pas le rôle de clé primaire dans une autre relation. Dans FICHE_DOSSIER, idDossier est clé primaire et étrangère à la fois car idDossier est aussi clé primaire dans la relation DOSSIER. numFiche n’existe que dans FICHE_DOSSIER. d) Dire si les affirmations suivantes sont vraies. 1. Une fiche n’appartient qu’à un seul dossier. VRAI : la cardinalité 1,1 montre bien qu’une fiche n’est rattachée qu’à un seul dossier. Le lien identifiant rend cette affirmation encore plus forte : la fiche dépend du dossier. 2. Un dossier peut comporter plusieurs fiches. VRAI : du côté de DOSSIER, la cardinalité est de 0,n. Cela prouve que pour un dossier, il peut y avoir 0 à n fiches. 3. Une fiche peut concerner plusieurs clients. FAUX : une fiche n’appartient qu’à un dossier qui lui-même n’appartient qu’à un seul client. Donc une fiche ne peut concerner qu’un seul client. 4. Un client peut posséder plusieurs fiches. VRAI : un client peut posséder plusieurs dossiers (cardinalité 0,n du côté de client) et un dossier peut posséder plusieurs fiches. Donc un client peut posséder plusieurs fiches.

8 2955 TG PA 00

Exercice 6 a) Construire le SCD.

Sans utiliser les possibilités de Merise/2, on est obligé de créer les entités DATE et NUMERO pour dessiner les associations RV et OPERATION. De plus, le fait que OPERATION est directement lié à RV (ce qui apparaît dans les relations) n’apparaît plus avec ce formalisme.

Séquence 6 Autocorrection

Page 179

Cette représentation, reprenant la notion de lien identifiant de Merise/2, est nettement plus légère est visuelle. Remarquez que le lien identifiant est noté (R) pour "identifiant Relatif", comme cela a été expliqué dans le cours (voir la partie qui présente les différentes notations du lien identifiant). C’est en fait la notation sous Win’Design.

8 2955 TG PA 00

b) Répondre aux questions suivantes. Un patient peut-il consulter plusieurs médecins ? OUI Même si, pour un RV il ne peut y avoir qu’un seul médecin concerné, le patient peut avoir un médecin différent à chaque RV. Plusieurs opérations peuvent-elles se faire durant un seul rendez-vous ? OUI C’est encore plus visible sur le second schéma où l’on voit clairement que les opérations sont numérotées par RV (1re opération du RV, 2e opération du RV…). Un rendez-vous peut-il concerner plusieurs médecins ? NON Pour un RV, il ne peut y avoir qu’un seul médecin la cardinalité 1,1 entre RV et MEDECIN du côté de RV le montre. Un patient peut-il prendre plusieurs rendez-vous le même jour ? NON La clé primaire de RV est idPatient+date. Cette clé devant être unique, il n’est pas possible d’avoir plusieurs fois le même patient à la même date. Si l’on avait voulu pouvoir enregistrer plusieurs RV d’une même personne le même jour, il aurait fallu ajouter heure_deb en 3e clé primaire de RV ou remplacer date par dateheure (DateTime). c) Si le cabinet ne comportait qu’un seul médecin, quelle modification faudrait-il apporter au schéma ? Il faudrait enlever l’entité MEDECIN et le lien entre RV et MEDECIN. Inutile d’avoir une entité qui mémorise la liste des médecins s’il n’y en a qu’un. Séquence 6 Autocorrection

Page 180

Cependant, si vous avez répondu : enlever le lien entre RV et MEDECIN et transformer l’entité MEDIN en entité paramètre, donc sans identifiant et avec un seul tuple, c’est juste aussi. d) nouveau schéma :

Cette version montre que, pour repérer un congé, il est nécessaire de connaître le médecin concerné et la date de départ (car il peut y avoir plusieurs congés à des dates différentes.

8 2955 TG PA 00

Voici la représentation du congé avec un lien identifiant (pour éliminer l’entité DATE) :

Exercice 7 a) Correction d’erreurs :

Séquence 6 Autocorrection

Page 181

8 2955 TG PA 00

Erreur n°1 : "sachant qu’un livre n’a qu’un auteur" donc c’est une CIF qui va de LIVRE vers AUTEUR. C’est votre premier schéma complet. Désolée mais il y avait déjà un petit piège dans

Erreur n°2Il: est "Le question prix variede d’un livre à l’autre, même livre" le sujet. «catalogue» mais mais il ne reste fallaitfixe paspour faireund’entité «catadonc le prix ne dépend pas de l’exemplaire mais uniquement du? livre. logue». Posez-vous la question : combien y-a-t-il de catalogue Un seul : donc vous n’allezn°3 pas: "On faireconnaît une entité pourl’adresse ça. En fait, le tel butdes estclients" de stocker toutes les informaErreur le nom, et le donc il manque le tel. tions dont vous avez besoin pour créer ce catalogue. De quoi avez-vous besoin Des Erreur n°4 : "L’historique des prêts doit être mémorisé, avec la date de prêt et la ?date informations sur les articles (contenues dans l’entité ARTICLE) et des informations de retour" donc il manque la date de retour. sur les CATEGORIES (contenues dans l’entité CATEGORIE). Le lien entre ARTICLE et b)CATEGORIE Pour déterminer on a besoin d’un exemplaire les 2de liens vers permetun dePRET, connaître la catégorie de chaque précis article,(d’où et donc pouvoir LIVRE ET NUMERO pour récupérer les 2 identifiants d’EXEMPLAIRE) et d’une date. les trier sur ce critère. Inutile d’avoir plus d’identifiant puisqu’un livre (un exemplaire) ne peut pas être Autre point intéressant du sujet : le prix «fournisseur» de chaque article. Le sujet prêté plusieurs fois le même jour. C’est donc le lien direct vers CLIENT qui est inutile explique que chaque article peut être acheté au près de plusieurs fournisseurs. Il et qu’il faut remplacer par une CIF (pour avoir, dans PRET, une clé étrangère pour est évident que chaque fournisseur peut proposer plusieurs articles. Donc il fallait connaître le client qui a emprunté cet exemplaire). faire une association entre ARTICLE et FOURNISSEUR. Le prix_fournisseur est dans c)l’association nouveau schéma : car il concerne un article pour un fournisseur précis (chaque fournisseur a ses propres prix). Relations correspondantes :

Séquence 6 Autocorrection

Page 182

ARTICLE (idArticle, nom, prix_vente, idCategorie) idArticle : clé primaire idCategorie : clé étrangère en réf. à idCategorie de CATEGORIE CATEGORIE (idCategorie, libellé) idCategorie : clé primaire FOURNISSEUR (idFournisseur, nom, adresse, tel) idFournisseur : clé primaire ARTICLE_FOURNISSEUR (idArticle, idFournisseur, prix_fournisseur) idArticle, idFournisseur : clé primaire idArticle : clé étrangère en réf. à idArticle de ARTICLE idFournisseur : clé étrangère en réf. à idFournisseur de FOURNISSEUR

Encore un petit piège dans ce sujet : il est question de patient et de dossier, mais en réalité c’est la même chose. Il ne fallait pas faire 2 entités différentes. Un patient n’a qu’un dossier et un dossier ne concerne qu’un patient. Et d’ailleurs, que pourriez vous mettre comme information dans dossier, en dehors des informations qui sont déjà dans patient ? Autre point intéressant du sujet : les passages. Comment repérer un passage ? On pourrait très bienencore faire une avecce unschéma numéroest séquentiel Mais àlelire. sujet Vous remarquez, uneentité fois, que plus légerclassique. et plus facile précise qu’une personne ne peut pas «entrer» 2 fois le même jour. Donc un passage d) les relations repéré, : est clairement pour chaque patient, par la date d’entrée. Il fallait faire de LIVRE (idLivre, titre, prix, idAuteur) passage une association entre PATIENT et DATE, ou une entité avec un lien identifiant primaireen identifiant relatif. vers idLivre PATIENT :et clé date_entrée idAuteur : clé étrangère en réf. à idAuteur de AUTEUR

Voici la première version AUTEUR (idAuteur, nom):

idAuteur clé le primaire Et une seconde: avec lien identifiant pour éviter l’entité DATE : THEME (idTheme, libellé)

Relations correspondantes (ce sont les mêmes pour les 2 solutions) : idTheme : clé primaire

PATIENT (idPatient, nom, adresse, tel) THEME_LIVRE (idLivre, idTheme) idPatient : clé primaire idLivre, idTheme : clé primaire PASSAGE (idPatient, date_entree, motif, date_sortie) idLivre : clé étrangère en réf. à idLivre de LIVRE idPatient, date_entree : clé primaire idTheme : clé étrangère en réf. à idTheme de THEME idPatient : clé nom, étrangère en réf. CLIENT (idCLient, adresse, tel) à idPatient de PATIENT

8 2955 TG PA 00

idClient : clé primaire RESERVATION (idLivre, idClient) idLivre, idClient : clé primaire idLivre : clé étrangère en réf. à idLivre de LIVRE idClient : clé étrangère en réf. à idClient de CLIENT EXEMPLAIRE (idLivre, numExemplaire, sortie, etat) idLivre, numExemplaire : clé primaire idLivre : clé étrangère en réf. à idLivre de LIVRE PRET(idLivre, numExemplaire, date_emprunt, date_retour, idClient) idLivre, numExemplaire, date_emprunt : clé primaire idLivre, numExemplaire : clé étrangère en réf. à (idLivre, numExemplaire) de EXEMPLAIRE idClient : clé étrangère en réf. à idClient de CLIENT

Exercice 8

Séquence 6 Autocorrection

C'est votre premier schéma complet. Désolée mais il y avait déjà un petit piège dans le sujet. Il est question de "catalogue" mais il ne fallait pas faire d'entité "catalogue". Posez-vous la question : combien y-a-t-il de catalogue ? Un seul : donc vous n'allez pas faire une entité pour ça. En fait, le but est de stocker toutes les informations dont vous avez besoin pour créer ce catalogue. De quoi avez-vous besoin ? Des informations sur les articles (contenues dans l'entité ARTICLE) et des informations sur les CATEGORIES (contenues dans l'entité CATEGORIE). Le lien entre ARTICLE et CATEGORIE permet de connaître la catégorie de chaque article, et donc de pouvoir les trier sur ce critère.

Page 183

Autre point intéressant du sujet : le prix "fournisseur" de chaque article. Le sujet explique que chaque article peut être acheté auprès de plusieurs fournisseurs. Il est évident que chaque fournisseur peut proposer plusieurs articles. Donc il fallait faire une association entre ARTICLE et FOURNISSEUR. Le prix_fournisseur est dans l'association car il concerne un article pour un fournisseur précis (chaque fournisseur a ses propres prix). Relations correspondantes : ARTICLE (idArticle, nom, prix_vente, idCategorie) idArticle : clé primaire idCategorie : clé étrangère en réf. à idCategorie de CATEGORIE CATEGORIE (idCategorie, libellé) idCategorie : clé primaire FOURNISSEUR (idFournisseur, nom, adresse, tel) idFournisseur : clé primaire ARTICLE_FOURNISSEUR (idArticle, idFournisseur, prix_fournisseur) idArticle, idFournisseur : clé primaire idArticle : clé étrangère en réf. à idArticle de ARTICLE idFournisseur : clé étrangère en réf. à idFournisseur de FOURNISSEUR 8 2955 TG PA 00

Exercice 9 Encore un petit piège dans ce sujet : il est question de patient et de dossier, mais en réalité c’est la même chose. Il ne fallait pas faire 2 entités différentes. Un patient n’a qu’un dossier et un dossier ne concerne qu’un patient. Et d’ailleurs, que pourriezvous mettre comme information dans dossier, en dehors des informations qui sont déjà dans patient ? Autre point intéressant du sujet : les passages. Comment repérer un passage ? On pourrait très bien faire une entité avec un numéro séquentiel classique. Mais le sujet précise qu’une personne ne peut pas "entrer" 2 fois le même jour. Donc un passage est clairement repéré, pour chaque patient, par la date d’entrée. Il fallait faire de passage une association entre PATIENT et DATE, ou une entité avec un lien identifiant vers PATIENT et date_entrée en identifiant relatif. Voici la première version :

Et une seconde avec le lien identifiant pour éviter l’entité DATE :

Séquence 6 Autocorrection

Page 184

Relations correspondantes (ce sont les mêmes pour les 2 solutions) : PATIENT (idPatient, nom, adresse, tel) idPatient : clé primaire PASSAGE (idPatient, date_entree, motif, date_sortie) idPatient, date_entree : clé primaire idPatient : clé étrangère en réf. à idPatient de PATIENT

Exercice 10

Cet exercice reprend les mêmes exemples que le cours.

8 2955 TG PA 00

LANGUE (idLangue, libellé) idLangue : clé primaire VILLE (idVille, nom) idVille : clé primaire DISTANCE (idVille1, idVille2, distance) idVille1, idVille2 : clé primaire idVille1 : clé étrangère en réf. à idVille de VILLE idVille2 : clé étrangère en réf. à idVille de VILLE SEJOUR (idSejour, dateDepart, dateRetour, idVilleDep, idVilleAr, idLangue) idSejour : clé primaire idVilleDep : clé étrangère en réf. à idVille de VILLE idVilleAr : clé étrangère en réf. à idVille de VILLE idLangue : clé étrangère en réf. à idLangue de LANGUE

Exercice 11

Séquence 6 Autocorrection

Page 185

Cet exercice aborde l’héritage. Les informations étaient clairement précisées : soit concernant les particuliers, soit concernant les entreprises, soit les 2. Le fait que le fax puisse concerner parfois les particuliers fait de cet attribut un attribut commun aux 2. CLIENT (idClient, adresse, tel, fax) idClient : clé primaire PARTICULIER (idClient, nom, prenom) idClient : clé primaire idClient : clé étrangère en réf. à idClient de CLIENT ENTREPRISE (idClient, raison_sociale, siret, idCategorie) idClient : clé primaire idClient : clé étrangère en réf. à idClient de CLIENT idCategorie : clé étrangère en réf. à idCategorie de CATEGORIE CATEGORIE (idCategorie, libellé) idCategorie : clé primaire

8 2955 TG PA 00

Exercice 12 Question 1 : SCD correspondant aux relations

Question 2 : affirmations

VRAI FAUX

a) Un droïde possède une date de fabrication et une date de mise en service. ¢ Ces attributs sont effectivement présents dans l’entité DROIDE. b) Un droïde n’appartient qu’à un seul type (droïdekas, droïde de combat, droïde de soutien, droïde médical tripode, astro-droïde…). ¢ C’est le cas puisqu’il y a une CIF qui va de DROIDE à TYPEDROIDE. Séquence 6 Autocorrection

Page 186

c) Un type de droïde possède une durée de vie. Il manque l’attribut correspondant dans TYPEDROIDE.

£

£

¢

£

¢

¢

£

¢

£

g) Pour chaque arme, la quantité de munitions stockable varie suivant le type de droïde. £ Cette information devra être portée par l’association précédente.

¢

d) Chaque droïde fabriqué est numéroté par rapport à  son type (1er droïde de combat, 2e droïde de combat… 1er droïdekas, 2e droïdekas, 3e droïdekas…) Il n’y a pas de lien identifiant entre DROIDE et TYPEDROIDE. e) Pour chaque arme, il faut connaître son nom, sa puissance et sa portée. Les 3 attributs correspondants sont bien dans l’entité ARME f) Chaque type de droïde peut manipuler certaines armes, il faut savoir lesquelles. Il manque une association entre TYPEDROIDE et ARME pour avoir cette information.

h) Il faut connaître la quantité fabriquée de chaque arme. £ Cette information devra être portée par l’entité ARME. i) Un droïde a un nom qui lui est propre et qui le qualifie en plus de son type et de son numéro (ex : R2D2, R4G9 sont les noms de 2 astro-droïdes). L’attribut nom est bien présent dans DROIDE. j) Il faut mémoriser la date de désactivation d’un droïde. Cette date devra être présente dans DROIDE.

8 2955 TG PA 00

£

¢

¢

£

£

¢

Question 3 : relations SYSTEME (n°systeme, nom) n°systeme : clé primaire PLANETE (n°planete, nom, n°systeme) n°planete : clé primaire n°systeme : clé étrangère en réf. à n°systeme de SYSTEME BATAILLE (n°planete, date_deb) n°planete, date_deb : clé primaire n°planete : clé étrangère en réf. à n°planete de PLANETE

Question 4 : modifications

Pour éviter de garder une entité DATE, l'association BATAILLE a été transformée en entité faible : cependant ce n'était pas demandé. Si vous avez laissé l'association BATAILLE, c'est elle qui doit contenir les attributs date_fin et gagnant, et c'est d'elle que doit partir la CIF vers TYPEBATAILLE. Si vous avez fait de LIEU une entité faible, c'est aussi très bien.

Séquence 6 Autocorrection

Page 187

Exercice 13 A) SCD issu des relations :

La difficulté est au niveau de LienAffaire, qui est tout de même bien expliqué dans le sujet. C'est non seulement une association réflexive mais en plus elle possède une clé étrangère (d'où la CIF qui part de l'association). Cependant, il n'y a en fait rien

8 2955 TG PA 00

de particulier : toutes les règles de passage du schéma relationnel au schéma conceptuel sont respectées : LienAffaire possède 2 clés primaires donc c'est une association avec 2 liens directs. Pourquoi il n'y a pas de flèche sur le lien entre LienAffaire et Raison ? Juste pour vous rappeler que la flèche n'est pas obligatoire. B) extrait des relations INVESTIGATION (dateInvestigation, duree, lieu, commentaire, resultat, kilométrage, nbnuits, totalfrais, dateRemboursement, numAffaire) dateInvestigation : clé primaire numAffaire : clé étrangère en réf. à numAffaire de AFFAIRE INTERVENANT (numAgent, dateInvestigation) numAgent, dateInvestigation : clé primaire numAgent : clé étrangère en réf. à numAgent de AGENT dateInvestigation : clé étrangère en réf. à dateInvestigation de INVESTIGATION AGENT (numAgent, nom, portable, email) numAgent : clé primaire AFFAIRE (numAffaire, dateOuverture, dateCloture, commentaire, resultat, responsable) numAffaire : clé primaire

C) affirmations Séquence 6 Autocorrection

Page 188

VRAI FAUX

a) L  es investigations sont identifiées par l'affaire concernée et la date de l'investigation (il ne peut donc pas y avoir plusieurs investigations le même jour pour la même affaire, cependant il peut y avoir plusieurs investigations le même jour pour des affaires différentes). ¨ Les investigations ne sont identifiées que par dateInvestigation. Il n'y a pas de lien identifiant pour récupérer aussi l'affaire en clé primaire (comme suggéré ici). b) Une investigation est affectée à un ou deux agents. Mauvaise lecture de la cardinalité : d'après le SCD, un Agent ne peut être affecté qu'à 1 ou 2 investigations (ce qui est nul, mais c'est marqué comme ça !).

¨

c) P  our chaque investigation, il faut mémoriser la durée, le lieu, un commentaire précis de la raison de l'investigation, ainsi que le résultat. ¨ Tous ces attributs sont bien dans l'entité INVESTIGATION. d) P  our chaque investigation, il faut connaître le ou les éventuel(s) transport(s) utilisé(s) (il existe une liste précise de transports possibles). Ce point est correctement modélisé : l'association TRANSPORT_UTILISE donne la liste des transports et la cardinalité 0,n correspond bien aux attentes (le ou les "éventuels"… donc il peut n'y en avoir aucun).

8 2955 TG PA 00

¨

¢

¢

¢

¢

e) P  our chaque investigation, il faut connaître le ou les éventuel(s) hôtel(s) utilisé(s) (il existe une liste d'hôtels avec leur nom, adresse, téléphone). ¨ Idem que le point précédent et HOTEL contient les attributs demandés. f) U  ne investigation donne éventuellement lieu à des frais de remboursement (s'il y a eu déplacements et/ou nuits d'hôtel). Ces remboursements sont réalisés en fonction des frais réels donc des factures fournies : le montant total, qu'il faut mémoriser, est ensuite divisé par le nombre d'agents. La date de remboursement n'est pas forcément la même pour chaque agent. ¨ totalFrais est bien mémorisé dans INVESTIGATION, mais la date de remboursement est mal placée : elle doit être dans INTERVENANT puisqu'elle peut être différente pour chaque agent.

¢

¢

g) U  ne affaire est numérotée et comporte une date d'ouverture, de clôture, un commentaire, un résultat et un agent qui sera responsable du suivi de l'affaire. ¨ ¢ Puisque le responsable de l'affaire est un agent, il faut aller le récupérer dans AGENT et non pas mettre un attribut responsable dans AFFAIRE (ce sera plutôt une clé étrangère numResponsable liée à AGENT). h) Il faut pouvoir joindre facilement chaque agent : on mémorise donc, en plus de leur nom, leur n° de portable et leur adresse email. ¨ Ces attributs sont bien dans AGENT. i) M  ême si une investigation est rattachée à une affaire, elle concerne parfois secondairement plusieurs autres affaires : il faut savoir lesquelles. Il manque une association entre INVESTIGATION et AFFAIRE, en plus de la CIF, pour avoir la liste des affaires secondaires.

¢ Séquence 6 Autocorrection

¨

¢

Page 189

j) P  our chaque transport utilisé pour une investigation, il faut mémoriser le kilométrage, et pour chaque hôtel utilisé pour une investigation, il faut mémoriser le nombre de nuits. ¨ ¢ Les attributs sont présents mais mal placés : kilometrage doit aussi être en fonction du transport (donc dans TRANSPORT_UTILISE) et nbnuits doit aussi être en fonction de l'hôtel (donc dans HOTEL_UTILISE). D) SCD correct Le schéma reprend toutes les explications précédentes.

8 2955 TG PA 00

Exercice 14 Séquence 6 Autocorrection

Cette fois le sujet est plus volumineux. La correction présentée est directement la version avec le lien identifiant pour gérer les visites : l'autre écriture est vraiment trop lourde.

Page 190

La modification demandée est assez complexe : pour chaque visite et chaque appareil, plusieurs séries peuvent être faites et il faut les distinguer pour mémoriser les poids par série. Il faut rajouter une troisième clé primaire à APPAREIL_UTILISE : un numéro de série. Du coup l'association ne contient plus que le poids. Voyons comment le représenter de façon jolie avec les liens identifiants :

8 2955 TG PA 00

Remarquez comment est construit SERIE : il possède 4 identifiants ! numSerie mais aussi numVisite+idAdherent (de VISITE) et idAppareil. ADHERENT (idAdherent, nom, adresse, tel, date_inscription, poids_initial, taille) idAdherent : clé primaire SPORT (idSport, nom) idSport : clé primaire SPORT_PRATIQUE (idAdherent, idSport, niveau) idAdherent, idSport : clé primaire idAdherent : clé étrangère en réf. à idAdherent de ADHERENT idSport : clé étrangère en réf. à idSport de SPORT MUSCLE (idMuscle, nom) idMuscle : clé primaire APPAREIL (idAppareil, nom, poids_min, poids_max) idAppareil : clé primaire MUSCLE_CONCERNE (idAppareil, idMuscle) idAppareil, idMuscle : clé primaire idAppareil : clé étrangère en réf. à idAppareil de APPAREIL idMuscle : clé étrangère en réf. à idMuscle de MUSCLE VISITE (idAdherent, numVisite, date, heure, duree) idAdherent, numVisite : clé primaire idAdherent : clé étrangère en réf. à idAdherent de ADHERENT SERIE (idAdherent, numVisite, idAppareil, numSerie, poids) idAdherent, numVisite, idAppareil, numSerie : clé primaire idAdherent, numVisite : clé étrangère en réf. à (idAdherent, numVisite) de VISITE idAppareil : clé étrangère en réf. à idAppareil de APPAREIL

Séquence 6 Autocorrection

Page 191

8 2955 TG PA 00

Exercice 15 LIVREUR

Voyons comment traiter ce sujet étape par étape en analysant chaque paragraphe. Séquence 6 Autocorrection

Page 192

Un restaurant décide de développer un système de livraison de pizzas à domicile. Vous êtes chargé de l’informatisation de cette activité en répondant aux deux objectifs principaux : • obtenir des livraisons les plus rapides possibles ; • garder le plus d’informations possibles sur les clients pour les fidéliser. Cette introduction ne sert à rien, excepté présenter le contexte. Les commandes se font par téléphone. Un client appelle et demande une ou plusieurs pizzas. À partir de là, on imagine déjà la gestion d'une commande (entité COMMANDE) rattachée à un client (entité CLIENT). L'air de rien, l'introduction précédente a apporté une information importante : il faut garder le plus d'informations possibles sur les clients pour les fidéliser. Donc pas de doute, toutes les commandes vont être enregistrées. En revanche, le fait que la commande se fasse par téléphone n'a aucune importance. Autre information : les pizzas. On peut déjà faire une entité PIZZA (avec le nom) et une association entre COMMANDE et PIZZA pour avoir les pizzas commandées. Soit il précise les noms exacts qu’il aura pris sur le prospectus du restaurant, soit il précise vaguement ce qu’il désire et l’opératrice devra le conseiller. On a déjà mis le nom dans PIZZA. L'histoire du prospectus, ou des conseils de l'opératrice, on s'en moque totalement. Un client peut, bien sûr, commander plusieurs pizzas identiques ou différentes. Il faut ajouter une quantité dans l'association LIGNE_COMMANDE. Chaque pizza est caractérisée par son nom, la description de ses ingrédients principaux (simplement le nom des ingrédients, comme jambon, fromage, sans les quantités...).

8 2955 TG PA 00

Il faut ajouter la description dans PIZZA. En ce qui concerne les ingrédients, c'est une gestion de liste avec des informations qui vont régulièrement être utilisées (plusieurs pizzas ont du jambon). De plus, pour conseiller le client, il est préférable de pouvoir faire facilement des recherches sur les ingrédients. Donc une entité INGREDIENT s'impose avec une association entre cette entité et PIZZA. Chaque pizza est proposée avec 3 tailles différentes (mini, normale ou maxi). Le client doit donc aussi préciser la taille de chacune des pizzas commandées. Il faut ajouter un 3e lien autour de l'association LIGNE_COMMANDE pour prendre en compte la taille (car si vous mettez taille directement dans l'association, si le client commande une Royale en taille maxi, il ne pourra pas commander en même temps une Royale en taille normale). Ceux qui ont géré la ligne de commande en entité faible avec la taille en identifiant relatif et 2 liens identifiants (vers COMMANDE et vers PIZZA) : bravo. Le prix d’une pizza dépend bien sûr de la pizza choisie et de sa taille. En fait, le prix de la mini est toujours 20% moins élevé que la normale, et le prix de la maxi 20% plus élevé. Joli piège. Puisque le prix dépend de la pizza et de la taille, on a spontanément envie de faire une association entre PIZZA et TAILLE pour mémoriser le prix. Mais en réalité le prix s'obtient par un calcul : un pourcentage en fonction de la taille. Donc il suffit de mémoriser le prix de la pizza normale directement dans PIZZA et éventuellement le pourcentage à appliquer dans TAILLE (je dis "éventuellement" car cette information semble stable et la même dans un sens et dans l'autre, idem pour les tailles, donc est-ce que ça vaut le coup de mémoriser cette information dans TAILLE et du coup de garder dans le système une table TAILLE ? c'est discutable : je choisis de ne pas la garder). Pour chaque commande, l’opératrice doit noter le nom du client, son adresse précise et son numéro de téléphone.

Séquence 6 Autocorrection

Page 193

Il faut compléter l'entité CLIENT avec les informations nécessaires. Une fois la commande passée, les pizzas sont aussitôt fabriquées puis livrées dans les délais les plus brefs. Voilà une phrase qui ne sert à rien ! (en tout cas, pour notre SCD) Plusieurs livreurs s’occupent de ce travail. Pour chaque commande, il faut mémoriser le livreur qui s'en est occupé (en cas de réclamation). Il faut une entité LIVREUR et une CIF qui va de COMMANDE vers LIVREUR pour mémoriser qui est responsable de la commande. Afin de personnaliser l’accueil téléphonique des clients et de les fidéliser au maximum, on désire garder le détail de toutes leurs précédentes commandes dans le but d’afficher rapidement ces informations. Déjà fait ! L’opératrice pourra donc tout de suite proposer au client ses anciens choix (pour donner l’impression qu’elle se souvient de lui) ainsi que ses coordonnées. Si c’est un nouveau client, elle le saura donc tout de suite et pourra éventuellement le conseiller. Encore des informations qui ne servent à rien. La fidélisation des clients se fait aussi à travers des réductions. Celles-ci fonctionnent très simplement : sur l’ensemble des commandes, la 10e pizza est gratuite.

8 2955 TG PA 00

Simple calcul puisqu'on a l'historique complet des commandes. Ceci dit, ça me donne envie de mettre le total de la facture dans COMMANDE. Quel est l'intérêt puisqu'on peut le calculer (avec le prix de chaque pizza et sa quantité) ? Imaginez que les prix augmentent avec le temps (très envisageable) : si vous voulez recalculer le montant d'anciennes factures, c'est mort. Donc cet attribut total n'est pas en trop et sera automatiquement rempli à chaque fois qu'une commande est enregistrée. Le paiement de la commande peut se faire soit directement au téléphone (Carte bleue), soit à la livraison (chèque ou liquide). Il faut aussi mémoriser si la commande a été payée. Une entité TYPE_PAIEMENT va permettre d'avoir la liste des types de paiements possibles (on ne sait jamais, cette liste pourrait s'allonger : tickets restau…). Une CIF entre COMMANDE et cette entité permet de savoir quel moyen de paiement a été utilisé. Le système présente un seul type de paiement par commande, d'où la CIF. Si vous voulez permettre plusieurs types de paiements pour une même commande, il faudra alors faire une association et mettre un montant dans l'association (pour mémoriser le montant pour chaque type de paiement). Pour mémoriser si une commande a été payée, un simple booléen suffit (réglé). Voici les relations correspondantes :

Séquence 6 Autocorrection

Page 194

TYPE_PAIEMENT (idTypePaiement, libellé) idTypePaiement : clé primaire CLIENT (idClient, nom, adresse, tel) idClient : clé primaire LIVREUR (idLivreur, nom) idLivreur : clé primaire COMMANDE (idCommande, date, réglé, total, idLivreur, idClient, idTypePaiement) idCommande : clé primaire idLivreur : clé étrangère en réf. à idLivreur de LIVREUR idClient : clé étrangère en réf. à idClient de CLIENT idTypePaiement : clé étrangère en réf. à idTypePaiement de TYPE_PAIEMENT PIZZA (idPizza, nom, description, prix) idPizza : clé primaire INGREDIENT (idIngredient, nom) idIngredient : clé primaire COMPOSITION (idPizza, idIngredient) idPizza, idIngredient : clé primaire idPizza : clé étrangère en réf. à idPizza de PIZZA idIngredient : clé étrangère en réf. à idIngredient de INGREDIENT LIGNE_COMMANDE (idCommande, idPizza, taille, quantite) idCommande, idPizza, taille : clé primaire idCommande : clé étrangère en réf. à idCommande de COMMANDE idPizza : clé étrangère en réf. à idPizza de PIZZA

En ce qui concerne TAILLE, comme je l'ai dit plus haut, ce n'est peut-être pas la peine de mémoriser les tailles, mais ce n'est pas faux de le faire.

Exercice 16 Ce sujet a été donné à l'épreuve du BTS Informatique de 1995 (basé sur un ancien référentiel qui a été réformé en 1997). Cependant, les fondements de l'analyse sont les mêmes : seules les technologies ont évoluées. D'ailleurs, l'utilisation de Merise/2 va faciliter l'étude de ce sujet.

8 2955 TG PA 00

Quand un sujet est un peu long, prenez l'habitude de tout lire avant de vous lancer, pour avoir une idée globale. La plupart des sujets comporte des annexes, comme celui-là. Pour une raison mystérieuse, les annexes font souvent peur aux étudiants, alors qu'au contraire, elles représentent une aide cruciale et très simple. Elles permettent de contrôler qu'aucun attribut n'a été oublié. En prenant le temps de lire en entier ce sujet, on s'aperçoit qu'il est plus judicieux de le traiter en partant de la fin : donc en gérant d'abord les vols, puis le voyage et enfin l'enregistrement. Une fois cette démarche adoptée, le sujet est en fait plutôt simple. Une dernière remarque avant de dévoiler la solution : certains sujets proposent (fortement) des identifiants. Par exemple, l'annexe 5 semble proposer un code spécial pour désigner les aéroports. Vous pouvez soit utiliser ce code comme identifiant (puisqu'on vous le suggère, pourquoi pas) cependant vous avez aussi le droit de garder votre méthode de numérotation automatique. Les 2 solutions seront acceptées. Pour changer, je vous propose une correction utilisant les identifiants suggérés.

Séquence 6 Autocorrection

Page 195

La principale difficulté du sujet réside dans le tri des informations. En effet, on vous raconte des tas de choses qui ne servent à rien comme l'endroit où doit se présenter le passager, et à quelle heure… D'où l'importance des annexes qui, elles, ne présentent que les attributs nécessaires. En commençant par la partie vol : on apprend qu'un vol a lieu toujours aux mêmes horaires (voilà pourquoi l'heure de départ et d'arrivée sont directement dans vol) et à certaines dates : pour connaître la liste des dates possibles, il faut une association entre VOL et une entité DATE. La correction présente la version avec un lien identifiant (pour éviter l'entité DATE). Un vol dessert toujours les 2 mêmes aéroports : c'est le cas de la double CIF entre VOL et AEROPORT. Puis, en ce qui concerne le voyage : il est question d'un billet qui comporte un code et un nom et prénom de passager (remarquez que le nom doit être séparé du prénom car dans certaines annexes, seul le nom apparaît). Un billet peut comporter plusieurs vols (à chaque fois un vol précis, donc avec une date) voilà pourquoi il y a une association entre DATE_VOL et BILLET avec une cardinalité 1,n côté BILLET (au moins un vol pour un billet). En regardant en détail l'annexe 1, on apprend pas mal de choses

8 2955 TG PA 00

sur le vol du billet : il a un rang (1er vol, 2e vol…) et une classe. Ces attributs sont à mettre dans VOL_BILLET. Si vous avez géré une entité VOL_BILLET avec le rang en identifiant relatif et un lien identifiant sur BILLET, c'est très bien. Il faut alors aussi penser à faire une CIF vers DATE_VOL. L'annexe 2 apporte une petite information supplémentaire : le n°enregistrement, qu'il faut aussi placer dans VOL_BILLET. Enfin, en ce qui concerne l'enregistrement, les seules informations supplémentaires portent sur les bagages. Ils sont directement rattachés au billet et il peut y en avoir plusieurs. Le poids de chaque bagage doit être mémorisé. J'aurais bien fait de BAGAGE une entité faible (en numérotant les bagages par billet) : ce n'est possible qu'en mettant ensuite dans BAGAGE, comme attribut simple, le vrai numéro. Il ne fallait donc surtout pas créer des entités pour la carte d'embarquement, la souche, la carte d'accès etc. Comme d'habitude, n'oubliez pas que votre SCD doit comporter les informations nécessaires pour réaliser tous les traitements, et uniquement cela. Si vous avez toutes les informations pour éditer tous ces documents, alors c'est parfait ! Il n'y a rien d'autre à faire. Le SCD ne doit pas être le reflet des traitements mais doit juste fournir les données pour effectuer les traitements.

Séquence 6 Autocorrection

Page 196

BILLET (idBillet, nom_passager, prenom_passager) idBillet : clé primaire BAGAGE (idBagage, poids, idBillet) idBagage : clé primaire idBillet : clé étrangère en réf. à idBillet de BILLET AEROPORT (codeAeroport, nom) codeAeroport : clé primaire VOL (idVol, heure_dep, heure_ar, codeAeroDep, codeAeroAr) idVol : clé primaire codeAeroDep : clé étrangère en réf. à codeAeroport de AEROPORT codeAeroAr : clé étrangère en réf. à codeAeroport de AEROPORT DATE_VOL (idVol, date) idVol, date : clé primaire idVol : clé étrangère en réf. à idVol de VOL VOL_BILLET(idBillet, idVol, date, rang, classe, n°enregistrement) idBillet, idVol, date : clé primaire idBillet : clé étrangère en réf. à idBillet de BILLET idVol, date: clé étrangère en réf. à (idVol, date) de DATE_VOL

Exercice 17 Ce sujet officiel a été donné en 2006, donc basé sur l'ancien référentiel mais cela ne change en rien l'approche à adopter pour modéliser les données. C'est le "schéma entité-association" qui est demandé. Si vous avez bien lu le cours, vous savez que c'est un autre nom pour parler du SCD.

8 2955 TG PA 00

Vous voyez que le résultat ne fait pas vraiment peur.

Séquence 6

Cependant, comme dans tous les sujets officiels (et aussi dans les sujets portant sur de vrais projets), le plus complexe et de faire le tri et de trouver les bonnes informations.

Autocorrection

Dans la partie "terrasses" : les informations données sont le type de terrasse, la surface et l'établissement concerné. Le petit tableau montre la numérotation des terrasses par rapport aux établissements : c'est un lien identifiant (pour l'établissement 52, les terrasses portent les identifiants 521 et 522). Il fallait le voir ! Le tableau donne aussi la date d'installation (qui concerne chaque terrasse).

Page 197

Dans la partie "tarifs" : le tarif dépend du type de terrasse et de la zone, d'où l'association TYPETERRASSE_ZONE pour porter ce tarif. Les problèmes des terrasses installées en cours de période ne nous intéressent pas : c'est un simple calcul et on a tous les éléments nécessaires (date installation, tarif…). L'annexe 1 donne des précisions sur les types de terrasses : le libellé mais aussi la date d'ouverture et de fermeture. Dans la partie "établissements" : il faut mémoriser le nom et l'adresse et rattacher l'établissement à une zone (une seule). Du coup, la zone de la terrasse sera connue en passant par l'établissement. Dans la partie "personnes physiques" : des informations sur les exploitants sont à mémoriser. Pour le moment le sujet incite à lier ETABLISSEMENT avec EXPLOITANT. La suite du sujet présente le cas du changement d'exploitant. Du coup, il faut gérer les différentes exploitations, repérées par les dates, pour chaque établissement (d'où le lien identifiant sur ETABLISSEMENT). Les informations données en fin de sujet représentent les traitements qui doivent pouvoir être réalisés avec les données mémorisées dans le système. À la lecture de ces traitements, il n'y a rien à changer. S'il y avait un historique à gérer, il faudrait ajouter des dates partout… Mais le sujet dit clairement que les informations ne sont que celles qui portent sur une année.

8 2955 TG PA 00

Exercice 18

Séquence 6 Autocorrection

Page 198

Vous commencez normalement à avoir un certain recul pour construire ce type de schéma. Voyons donc uniquement les points intéressants du sujet. Il fallait avant tout repérer l'héritage sur TRIATHLETE. Il était facile à voir avec les 2 licences présentées en exemple où l'on peut voir que tout est identique excepté le club et la date de première licence, spécifiques aux licences de type club. Du coup, il ne fallait faire qu'un seul sous-type. INSCRIPTION est une entité faible : c'est clairement exposé dans le sujet puisqu'il est dit que l'inscription utilise le numéro de dossard ajouté au numéro du triathlon. Enfin, en ce qui concerne les entraîneurs du club : puisqu'il peut y en avoir plusieurs par club c'est une cardinalité 0,n du côté de CLUB (ou 1,n), mais attention, les entraîneurs étant obligatoirement licenciés du club, la cardinalité côté TRIATHLETE_CLUB est 0,1 (le triathlète est soit entraîneur de son club, soit non, mais il ne peut pas être entraîneur d'un autre club). Enfin, vous avez peut-être fait une entité SPORT et du coup des associations avec TYPE_TRIATHLON (pour les distances) et avec INSCRIPTION (pour les temps). C'est juste. Mais comme un triathlon représente forcément toujours 3 sports et les 3 mêmes sports, la solution proposée évite dans le système d'information, de créer 3 tables supplémentaires (issues de l'entité SPORT et des 2 associations supplémentaires).

8 2955 TG PA 00

Exercice 19

2 types de prestations sont clairement identifiés. Cependant, la création de l'entité fille WEEK_END n'est pas nécessaire puisqu'elle ne comporte aucune information spécifique. Il fallait repérer l'entité faible CRITERE (le sujet présente bien comment l'identifiant de CRITERE est construit).

Séquence 6 Autocorrection

Page 199

Les 2 annexes présentent 2 tableaux qu'il faut correctement décrypter. Le premier tableau présente un exemple de tarifs pour une cure. Ce tableau montre bien que le tarif dépend de la prestation, de la saison mais aussi de l'année (il faut garder un historique sur plusieurs années). Donc pour accéder au tarif, si vous avez fait une association ternaire, c'est juste. La solution proposée permet de limiter les liens autour des associations TARIF_PREST_SAISON et TARIF_HEBERGEMENT. Pour chaque saison et chaque année, il y a des périodes spécifiques : il fallait remarquer qu'il pouvait y avoir plusieurs périodes ! Le second tableau présente les tarifs d'hébergement. Celui-ci est encore plus complexe. En l'observant bien, on s'aperçoit que le tarif dépend de la saison, de l'année mais aussi du type de chambre (chambre standard simple…) et de la situation (la vue : jardin, rue, mer). Cela donne une ternaire (association à 3 branches) parce que SAISON_ANNEE contient la saison et l'année.

8 2955 TG PA 00

3. Extensions sous Merise/2 Exercice 1 Cet exercice est l'occasion de voir si les liens identifiants ont été compris. Il n'y a aucune ambiguïté possible dans l'énoncé. Le seul lien identifiant qui n'est pas explicitement demandé dans le sujet est celui entre VILLE et PAYS. Cependant il paraît assez naturel de numéroter les villes par pays. Mais ce n'est pas faux de ne pas l'avoir fait. Le point le plus important se situe au niveau du SEJOUR : le sujet dit que le séjour est repéré par une destination (une ville) et une date. Il est clairement dit qu'il ne peut pas y avoir 2 séjours avec la même destination et la même date. Donc on attend de vous que vous identifiez le séjour non pas par un simple numéro mais en associant la ville et une date. Voilà pourquoi un lien identifiant est fait entre SEJOUR et VILLE, mais cette fois en utilisant date comme identifiant relatif dans SEJOUR. Les activités sont numérotées par séjour et les sous-activités par activité : plusieurs liens identifiants en cascade. Attention, le lien entre SEJOUR et OPTION doit être une simple association car une option peut se retrouver dans plusieurs séjours.

Séquence 6 Autocorrection

Page 200

Les relations qui en découlent permettent de bien mettre en lumière les dépendances créées par les liens identifiants. Attention aux clés étrangères qui du coup sont parfois multiples pour faire référence à des relations qui ont déjà une clé primaire composée (liens identifiants en cascade).

8 2955 TG PA 00

PAYS(idPays, nom) idPays : clé primaire VILLE(idPays, idVille, nom) idPays, idVille : clé primaire idPays : clé étrangère en réf. à idPays de PAYS TYPE_SEJOUR(idTypeSejour, nom) idTypeSejour : clé primaire OPTION(idOption, nom) idOption : clé primaire SEJOUR(idPays, idVille, date, tarif, durée, idTypeSejour) idPays, idVille, date : clé primaire idPays, idVille : clé étrangère en réf. à (idPays, idVille) de VILLE idTypeSejour : clé étrangère en réf. à idTypeSejour de TYPE_SEJOUR OPTION_POSSIBLE(idPays, idVille, date, idOption) idPays, idVille, date, idOption : clé primaire idPays, idVille, date : clé étrangère en réf. à (idPays, idVille, date) de SEJOUR idOption : clé étrangère en réf. à idOption de OPTION ACTIVITE(idPays, idVille, date, idActivité, nom, tarif) idPays, idVille, date, idActivité : clé primaire idPays, idVille, date : clé étrangère en réf. à (idPays, idVille, date) de SEJOUR SOUS_ACTIVITE(idPays,idVille,date,idActivité,idSousActivité,nom) idPays,idVille,date,idActivité,idSousActivité : clé primaire idPays, idVille, date, idActivité : clé étrangère en réf. à (idPays, idVille, date, idActivité) de ACTIVITE

Séquence 6 Autocorrection

Exercice 2 Il faut créer une entité TAILLE car la taille intervient à plusieurs niveaux : le prix des pizzas et aussi dans la commande. À partir de là, une première association binaire entre TAILLE et PIZZA permet de porter le prix des pizzas en fonction de la taille.

Page 201

Le sujet commence à devenir intéressant au niveau de la gestion des commandes. Une commande concerne éventuellement plusieurs pizzas dans des tailles différentes. Cela pourrait être une ternaire entre COMMANDE, PIZZA et TAILLE, mais c'est effectivement plus judicieux de faire une association entre COMMANDE et PRIX_PIZZA (qui récupère déjà PIZZA et TAILLE). Voici la première agrégation du sujet. La seconde vient justement se brancher sur la première. En effet, pour chaque pizza d'une taille précise commandée, il est possible de choisir plusieurs suppléments. Comme les suppléments sont les mêmes pour les pizzas de même type et de même taille, l'association SUPPLMENT est donc bien entre PIZZA_COMMANDE et INGREDIENT. Le reste du schéma ne posait pas de problème particulier. Si vous avez fait de COMMANDE une entité faible de CLIENT (lien identifiant), c'est plutôt une bonne idée.

8 2955 TG PA 00

Voici les relations correspondantes. Comme dans l'exercice précédent, remarquez bien les clés étrangères qui sont composées quand elles font référence à une association. Séquence 6 Autocorrection

Page 202

8 2955 TG PA 00

CLIENT(idClient, nom, prenom, adresse, tel, email) idClient : clé primaire COMMANDE(idCommande, date, heure, payée, livrée, idClient) idCommande : clé primaire idClient : clé étrangère en réf. à idClient de CLIENT TAILLE(idTaille, nom) idTaille : clé primaire PIZZA(idPizza, nom) idPizza : clé primaire INGREDIENT(idIngredient, nom) idIngredient : clé primaire INGREDIENT_PIZZA(idPizza, idIngredient) idPizza, idIngredient : clé primaire idPizza : clé étrangère en réf. à idPizza de PIZZA idIngredient : clé étrangère en réf. à idIngredient de INGREDIENT PRIX_PIZZA(idPizza, idTaille, prix) idPizza, idTaille : clé primaire idPizza : clé étrangère en réf. à idPizza de PIZZA idTaille : clé étrangère en réf. à idTaille de TAILLE PIZZA_COMMANDE(idCommande, idPizza, idTaille, quantité) idCommande, idPizza, idTaille : clé primaire idCommande : clé étrangère en réf. à idCommande de COMMANDE idPizza, idTaille : clé étrangère en réf. à (idPizza, idTaille) de PRIX_PIZZA SUPPLEMENT(idCommande, idPizza, idTaille, idIngredient) idCommande, idPizza, idTaille, idIngredient : clé primaire idCommande, idPizza, idTaille : clé étrangère en réf. à (idCommande,idPizza,idTaille) de PIZZA_COMMANDE idIngredient : clé étrangère en réf. à idIngredient de INGREDIENT

Exercice 3 La création de la commande est un standard : entités COMMANDE, PRODUIT et une association PRODUIT_COMMANDE entre les 2 pour avoir les produits de la commande et pour porter la durée de garantie. Les produits ne sont vendus qu'en un seul exemplaire. Si vous avez géré la commande en insérant des informations sur le client, ou si vous avez fait une entité CLIENT, bien sûr c'est tout à fait juste. Le problème intervient pour les produits achetés avec contrats : des informations sont spécifiques pour ces achats de produits. On est bien dans le cas d'un héritage. Il n'y a qu'un seul sous-type sur association car un seul cas particulier. Le sous-type porte les attributs spécifiques à ce cas et pointe sur TYPE_CONTRAT.

Les relations issues de ce schéma respectent les règles classiques de l'héritage : remarquez que dans PRODUIT_AVEC_CONTRAT, la clé primaire reprend la clé primaire du sur-type et la clé étrangère permet justement d'accéder au sur-type. PRODUIT(idProduit, nom, prix) idProduit : clé primaire COMMANDE(idCommande, date) idCommande : clé primaire TYPE_CONTRAT(idTypeContrat, libellé) idTypeContrat : clé primaire PRODUIT_COMMANDE(idCommande, idProduit, durée_garantie) idCommande, idProduit : clé primaire idCommande : clé étrangère en réf. à idCommande de COMMANDE idProduit : clé étrangère en réf. à idProduit de PRODUIT PRODUIT_AVEC_CONTRAT(idCommande, idProduit, date_effet, durée, montant, idTypeContrat) idCommande, idProduit : clé primaire idCommande, idProduit : clé étrangère en réf. à (idCommande, idProduit) de PRODUIT_COMMANDE idTypeContrat : clé étrangère en réf. à idTypeContrat de TYPE_CONTRAT

Séquence 6 Autocorrection

Page 203

Exercice 4 Le sujet annonce 3 catégories de produits, cependant seules 2 des 3 catégories comportent des informations spécifiques. Donc il est inutile de faire 3 sous-types : 2 suffisent. Du coup, la contrainte au niveau des sous-types est bien une contrainte d'exclusion : un produit ne peut pas être un plat et un menu en même temps. Cependant, un produit peut être autre chose qu'un plat ou un menu : il peut être une boisson. Les boissons ne se retrouveront que dans l'entité PRODUIT.

8 2955 TG PA 00

Remarquez aussi que les entités filles se comportent comme des entités classiques. Cet aspect est juste un petit rappel. Par exemple, vous voyez qu'on a tout à fait le droit de faire une association entre 2 entités filles. Sous Win'design, la contrainte est placée dans le triangle qui symbolise l'héritage. Dans cet exercice, vous avez peut-être été frustré de ne pas trouver de contrainte d'exclusion entre associations. Je préférais attendre que vous ayez abordé la notion de cours suivante (les pivots) pour faire un premier exercice dessus.

Séquence 6 Autocorrection

Page 204

Les relations issues de ce schéma sont, encore une fois, très intéressantes. Remarquez par exemple la relation PLAT_MENU, où les clés primaires ont été forcément renommées (impossible de laisser idProduit 2 fois), cependant elles font bien références aux idProduit des 2 entités filles. Remarquez que la contrainte n'a aucune incidence sur les relations. Ce n'est qu'au niveau du code que la contrainte intervient. INGREDIENT(idIngredient, nom) idIngredient : clé primaire CATEGORIE(idCategorie, nom) idCategorie : clé primaire PRODUIT(idProduit, nom, prix) idProduit : clé primaire MENU(idProduit) idProduit : clé primaire idProduit : clé étrangère en réf. à idProduit de PRODUIT PLAT(idProduit, idCategorie) idProduit : clé primaire idProduit : clé étrangère en réf. à idProduit de PRODUIT idCategorie : clé étrangère en réf. à idCategorie de CATEGORIE INGREDIENT_PLAT(idProduit, idIngredient) idProduit, idIngredient : clé primaire idProduit : clé étrangère en réf. à idProduit de PLAT idIngredient : clé étrangère en réf. à idIngredient de INGREDIENT PLAT_MENU(idMenu, idPlat) idMenu, idPlat : clé primaire idMenu : clé étrangère en réf. à idProduit de MENU idPlat : clé étrangère en réf. à idProduit de PLAT

8 2955 TG PA 00

Exercice 5 L'exercice représente l'application directe de la notion abordée en cours. Il faut 2 listes d'informations : c'est plus judicieux de faire 2 associations, d'autant plus que l'une porte une information et pas l'autre. L'exclusion entre les 2 associations sur le couple idPathologie+idMedicament est évidente : si un médicament est proscrit pour une pathologie, forcément il ne peut pas être conseillé pour la même pathologie.

Les relations ne posent pas de problèmes particuliers. Vous remarquez que, comme sur l'héritage, la contrainte n'a aucune incidence sur les relations. PATHOLOGIE(idPathologie, nom) idPathologie : clé primaire MEDICAMENT(idMedicament, nom) idMedicament : clé primaire MEDICAMENT_CONSEILLE(idPathologie, idMedicament, posologie) idPathologie, idMedicament : clé primaire idPathologie : clé étrangère en réf. à idPathologie de PATHOLOGIE idMedicament : clé étrangère en réf. à idMedicament de MEDICAMENT MEDICAMENT_PROSCRIT(idPathologie, idMedicament) idPathologie, idMedicament : clé primaire idPathologie : clé étrangère en réf. à idPathologie de PATHOLOGIE idMedicament : clé étrangère en réf. à idMedicament de MEDICAMENT

Séquence 6 Autocorrection

Page 205

Exercice 6 Il n'y a que 3 types de véhicules, un véhicule ne peut être que de l'un des 3 types. On est bien dans le cas de la contrainte de partition. Remarquez le lien identifiant entre MODELE et MARQUE : il n'était pas demandé, cependant cela paraît assez logique de référencer les modèles par marque. En revanche ne pensez surtout pas faire la même chose entre LEGER et MODELE : il n'est pas possible de référencer les véhicules légers par modèle car LEGER est un sous-type de VEHICULE donc il porte forcément comme identifiant celui de l'entité mère. Cet exemple permet aussi de voir qu'on peut avoir une contrainte à 3 branches.

8 2955 TG PA 00

Voici les relations qui découlent de ce schéma. Ce sont des relations classiques d'héritage. La contrainte n'apparaît toujours pas.

Séquence 6 Autocorrection

Page 206

MARQUE(idMarque, nom) idMarque : clé primaire MODELE(idMarque, idModele, nom) idMarque, idModele : clé primaire idMarque : clé étrangère en réf. à idMarque de MARQUE VEHICULE(idVehicule, photo) idVehicule : clé primaire LEGER(idVehicule, cv, idMarque, idModele) idVehicule : clé primaire idVehicule : clé étrangère en réf. à idVehicule de VEHICULE idMarque, idModele : clé étrangère en réf. à (idMarque, idModele) de MODELE UTILITAIRE(idVehicule, cubage) idVehicule : clé primaire idVehicule : clé étrangère en réf. à idVehicule de VEHICULE CAMION(idVehicule, tonnage, hauteur) idVehicule : clé primaire idVehicule : clé étrangère en réf. à idVehicule de VEHICULE

Exercice 7 La contrainte de totalité entre CONF_SEMINAIRE et TP_SEMINAIRE avec comme pivot idSeminaire, montre que idSeminaire doit se retrouver forcément dans l'une des 2 associations, voire les 2. Dit autrement, un séminaire a forcément une ou plusieurs conférences, ou un ou plusieurs TP, ou les 2. Même analyse pour la contrainte de totalité entre CONFERENCIER et la CIF qui représente le formateur du TP : un intervenant est forcément enregistré soit comme conférencier, soit comme formateur, soit les 2. Le sujet dit bien que les intervenants ne sont enregistrés que lorsqu'ils sont intervenus au moins une fois. Vous avez peut-être fait une entité LIEU et une CIF de SEMINAIRE vers LIEU : c'est tout à fait correct, voire même plutôt judicieux si plusieurs séminaires peuvent se dérouler dans le même lieu.

8 2955 TG PA 00

Si vous avez fait un héritage sur INTERVENANT, c'est dommage car vous traduisez le fait que certains intervenants sont soit des conférenciers, soit des formateurs, soit les 2. En quelque sorte vous donnez un titre aux intervenants alors que le sujet dit bien qu'un intervenant peut intervenir à tous les niveaux. Vous alourdissez le schéma avec 2 entités supplémentaires pour rien. C'est aussi dommage de faire l'héritage sur SEMINAIRE, même si cette solution se défend un peu plus que l'héritage précédent. En effet, cela alourdit le schéma mais il y a effectivement certains séminaires qui n'auront que des conférences, d'autres que des TP et enfin des séminaires qui auront les 2.

Séquence 6 Autocorrection

Voici les relations correspondantes. Vous remarquerez que j'ai volontairement mis dans TP, comme clé étrangère un nom d'attribut différent de la clé primaire d'INTERVENANT. Le but est double : montrer qu'on peut donner à une clé étrangère un nom plus parlant que la clé primaire à laquelle elle fait référence, et donc rappeler que le nom de la clé étrangère n'est pas forcément le même que celui de la clé primaire. J'ai utilisé le même principe dans CONFERENCIER.

Page 207

SEMINAIRE(idSeminaire, date, lieu, durée) idSeminaire : clé primaire INTERVENANT(idIntervenant, nom, tel) idIntervenant : clé primaire CONFERENCE(idConference, titre) idConference : clé primaire TP(idTP, objectif, durée, idFormateur) idTP : clé primaire idFormateur : clé étrangère en réf. à idIntervenant de INTERVENANT CONF_SEMINAIRE(idSeminaire, idConference) idSeminaire, idConference : clé primaire idSeminaire : clé étrangère en réf. à idSeminaire de SEMINAIRE idConference : clé étrangère en réf. à idConference de CONFERENCE TP_SEMINAIRE(idSeminaire, idTP) idSeminaire, idTP : clé primaire idSeminaire : clé étrangère en réf. à idSeminaire de SEMINAIRE idTP : clé étrangère en réf. à idTP de TP CONFERENCIER(idConference, idConferencier) idConference, idConferencier : clé primaire idConference : clé étrangère en réf. à idConference de CONFERENCE idConferencier : clé étrangère en réf. à idIntervenant de INTERVENANT 8 2955 TG PA 00

Exercice 8 Il y a contrainte d'égalité (simultanéité) entre RESPONSABLE et AUTEUR sur idProfesseur. Donc, si un idProfesseur se retrouve dans RESPONSABLE, il est forcément dans AUTEUR et vice versa. Dis clairement, un professeur est responsable d'au moins un cours s'il est auteur d'au moins une publication, et vice versa. Si vous avez fait une entité NIVEAU et une CIF de COURS vers NIVEAU, c'est tout à fait juste. En revanche, c'est bien une cardinalité 1,n du côté de PUBLICATION : le sujet dit "il a participé à une publication". Donc il peut y avoir plusieurs professeurs sur une même publication. Si vous avez mis 1,n du côté de COURS, ce n'est pas faux : vous partez du principe que dès la création d'un cours, vous lui affectez au moins un responsable.

Séquence 6 Autocorrection

Page 208

Voici les relations correspondantes. Si vous avez utilisé des noms différents de idProfesseur dans RESPONSABLE et AUTEUR, c'est plutôt une bonne idée (comme on l'a vu dans l'exercice précédent). COURS(idCours, nom, niveau) idCours : clé primaire PUBLICATION(idPublication, titre, date) idPublication : clé primaire PROFESSEUR(idProfesseur, nom, tel, email, chercheurON) idProfesseur : clé primaire RESPONSABLE(idCours, idProfesseur) idCours, idProfesseur : clé primaire idCours : clé étrangère en réf. à idCours de COURS idProfesseur : clé étrangère en réf. à idProfesseur de PROFESSEUR AUTEUR(idPublication, idProfesseur) idPublication, idProfesseur : clé primaire idPublication : clé étrangère en réf. à idPublication de PUBLICATION idProfesseur : clé étrangère en réf. à idProfesseur de PROFESSEUR

8 2955 TG PA 00

Exercice 9 Il était question de rédacteur en chef, de comité : bien sûr il ne fallait rien modéliser à ce niveau là. Si vous n'avez pas fait d'entité AUTEUR et que vous avez placé un attribut auteur directement dans ARTICLE, ce n'est pas très grave. On se doute juste que les auteurs écrivent plusieurs articles, donc c'est plus optimisé de faire une entité AUTEUR. Le point principal du sujet est bien sûr entre ARTICLE et RUBRIQUE. Il y a 3 étapes : les articles candidats, les articles choisis parmi les candidats et enfin les articles publiés issus des articles choisis (d'où les 2 contraintes d'inclusion).

Séquence 6 Autocorrection

Page 209

Les relations ne permettent pas de voir la cardinalité 0,1 : elle sera gérée dans la base de données en précisant que l'attribut idRubrique peut être nul. Au niveau des relations, certains ne mettent pas de référence sur une clé étrangère pour éviter justement le lien fort qui lie les 2 relations (le lien a été mis en italique). AUTEUR(idAuteur, nom) idAuteur : clé primaire ARTICLE(idArticle, titre, date, contenu, idAuteur, idRubrique) idArticle : clé primaire idAuteur : clé étrangère en réf. à idAuteur de AUTEUR idRubrique : clé étrangère en réf. à idRubrique de RUBRIQUE RUBRIQUE(idRubrique, nom) idRubrique : clé primaire ARTICLE_CANDIDAT(idRubrique, idArticle) idRubrique, idArticle : clé primaire idRubrique : clé étrangère en réf. à idRubrique de RUBRIQUE idArticle : clé étrangère en réf. à idArticle de ARTICLE ARTICLE_CHOISI(idRubrique, idArticle, ordre) idRubrique, idArticle : clé primaire idRubrique : clé étrangère en réf. à idRubrique de RUBRIQUE idArticle : clé étrangère en réf. à idArticle de ARTICLE

8 2955 TG PA 00

On pourrait aussi, pourquoi pas, imaginer une nouvelle relation entre ARTICLE et RUBRIQUE pour avoir juste les articles publiés. Cette solution se défend tout à fait, malgré la cardinalité 0,1, car il est sans doute regrettable d'ajouter un attribut idRubrique à tous les tuples de ARTICLE alors que seuls quelques couples suffiraient dans une nouvelle table pour donner la liste des articles publiés. Voici ce que cela donnerait : AUTEUR(idAuteur, nom) idAuteur : clé primaire ARTICLE(idArticle, titre, date, contenu, idAuteur) idArticle : clé primaire idAuteur : clé étrangère en réf. à idAuteur de AUTEUR RUBRIQUE(idRubrique, nom) idRubrique : clé primaire ARTICLE_CANDIDAT(idRubrique, idArticle) idRubrique, idArticle : clé primaire idRubrique : clé étrangère en réf. à idRubrique de RUBRIQUE idArticle : clé étrangère en réf. à idArticle de ARTICLE ARTICLE_CHOISI(idRubrique, idArticle, ordre) idRubrique, idArticle : clé primaire idRubrique : clé étrangère en réf. à idRubrique de RUBRIQUE idArticle : clé étrangère en réf. à idArticle de ARTICLE ARTICLE_PUBLIE(idRubrique, idArticle) idRubrique, idArticle : clé primaire idRubrique : clé étrangère en réf. à idRubrique de RUBRIQUE idArticle : clé étrangère en réf. à idArticle de ARTICLE Séquence 6 Autocorrection

Page 210

8 2955 TG PA 00

Exercice 10 Les étudiants ont généralement du mal à construire une contrainte d'inclusion à portée multiple. Comprenez bien le principe : vous devez trouver un ensemble inclus dans un grand ensemble. Le grand ensemble représente toujours l'association pointée par la flèche. Donc ici, on veut que les compétences nécessaires au stage soient INCLUSES dans les compétences du formateur. Le grand ensemble contient les compétences du formateur : l'association COMPETENCE_FORMATEUR. Cherchez ensuite les pivots : c'est classiquement les 2 entités qui entourent le grand ensemble puisque l'on cherche justement à s'inclure dans cet ensemble. Le pivot est donc le couple idFormateur+idCompetence. Il faut maintenant que ce couple soit obtenu en passant par le stage : car le but est que le formateur du stage ait les compétences requises pour ce stage. Les branches de l'inclusion portent donc sur les 2 autres associations : dans COMPETENCE_STAGE on va pouvoir récupérer un des pivots (idCompetence) et dans INTERVENANT on va récupérer l'autre (idFormateur), les 2 étant liés par STAGE (sinon ça ne marcherait pas, car il faut bien arriver à recréer le couple de pivots).

Voici les relations correspondantes (qui, comme d'habitude, ne traduisent pas la contrainte). STAGE(idStage, titre) idStage : clé primaire COMPETENCE(idCompetence, nom) idCompetence : clé primaire FORMATEUR(idFormateur, nom) idFormateur : clé primaire INTERVENANT(idStage, idFormateur) idStage, idFormateur : clé primaire idStage : clé étrangère en réf. à idStage de STAGE idFormateur : clé étrangère en réf. à idFormateur de FORMATEUR COMPETENCE_STAGE(idStage, idCompetence) idStage, idCompetence : clé primaire idStage : clé étrangère en réf. à idStage de STAGE idCompetence : clé étrangère en réf. à idCompetence de COMPETENCE COMPETENCE_FORMATEUR(idFormateur, idCompetence) idFormateur, idCompetence : clé primaire idFormateur : clé étrangère en réf. à idFormateur de FORMATEUR idCompetence : clé étrangère en réf. à idCompetence de COMPETENCE

Séquence 6 Autocorrection

Page 211

8 2955 TG PA 00

Exercice 11 L'association entre CLASSE et COURS permet d'avoir les cours d'une classe, sachant qu'un même cours peut se retrouver dans plusieurs classes différentes (le français, par exemple). Ensuite, puisque pour un cours donné dans une classe, il n'y a qu'un prof, on pourrait mettre le professeur dans l'association mais c'est plus logique de créer une entité PROFESSEUR et de faire une cif vers cette entité. À vous ensuite d'utiliser la représentation que vous préférez (contrainte d'unicité...).

Quelle que soit la représentation, les relations seront toujours les mêmes :

Séquence 6 Autocorrection

Page 212

CLASSE(idClasse, nom) idClasse : clé primaire COURS(idCours, nom) idCours : clé primaire PROFESSEUR(idProfesseur, nom) idProfesseur : clé primaire COURS_CLASSE(idClasse, idCours, nbHeures, idProfesseur) idClasse, idCours : clé primaire idClasse : clé étrangère en réf. à idClasse de CLASSE idCours : clé étrangère en réf. à idCours de COURS idProfesseur : clé étrangère en réf. à idProfesseur de PROFESSEUR

Exercice 12 Ce premier sujet ne comportait aucune contrainte sur association ou sur héritage ! C'est assez rare. En revanche, il fallait repérer un héritage et surtout un lien identifiant incontournable. Pour ce premier sujet, je vais vous livrer ma version (donc avec les choix habituels de présentation) suivie de la version de la correction officielle. Cela vous permettra de comparer et de commencer à vous habituer à différentes variantes de présentation. En dehors des nuances de présentation, j'ai fait quelques choix différents. Par exemple je n'ai pas vu l'utilité de mémoriser les communes : le sujet semble dire que l'on veut juste savoir si le verger est dans une commune AOC ou non. On peut légitimement se poser la question de l'intérêt de mémoriser des informations sur toutes les communes : les 2 solutions se défendent. Autre différence par rapport à la correction officielle : je ne mets jamais d'information explicite en identifiant : donc par exemple, pas de libellé en identifiant de VARIETE comme cela a été fait dans la correction officielle.

8 2955 TG PA 00

Ce sujet est très facile à comprendre et ne comporte aucun piège particulier. L'annexe 1B présente clairement le lien identifiant pour la gestion des lots (numérotés par livraison).

Séquence 6

Remarques complémentaires sur ce schéma

Autocorrection

L'héritage peut comporter les non adhérents avec une contrainte de partition (l'entité étant vide, ce n'est pas très utile).

Page 213

Le conditionnement peut être géré de façon plus précise, en séparant les libellés des quantités, en faisant 2 entités séparées et, soit une association entre les 2, soit un lien identifiant (de quantité vers libellé). L'association Conditionnement est alors soit en agrégation sur cette association, soit sur l'entité quantité (dans le cas du lien identifiant). Il est possible de gérer un type de client. Des CIF de Commande vers Calibre, TypeProduit et Variété sont acceptables (le choix du lot pouvant se faire a posteriori).

8 2955 TG PA 00

Voici la correction officielle suivi des commentaires officiels. Remarquez au passage le formalisme des CIF (de simples associations vides, mais la cardinalité permet de les repérer).

Séquence 6 Autocorrection

Page 214

Bloc 1 : les producteurs Entités : Producteur, Adhérent, Certification Associations : obtenir On accepte 2 sous-types avec une contrainte de partition Bloc 2 : les vergers Entités : Verger, Commune, Variété Associations : se situer, contenir, exploiter On acceptera un booléen "AOC obtenu" dans verger Bloc 3 : la production Entités : Calibre, Lot production, Livraison, Type (fraîches ou sèches) Associations : provenir, répartir, correspondre, être Bloc 4 : les campagnes de vente Entités : Client, Commande, Conditionnement Associations : passer, porter sur, comporter On peut trouver les entités : typeConditionnement et conditionnement (poids) à la place de Conditionnement On pourra trouver le traitement de la demande.

8 2955 TG PA 00

Exercice 13 À partir de cet exercice, seules les corrections officielles sont présentées et bien sûr commentées. Question 1 Le sujet est en 2 parties. Cette première partie est la construction classique d'un SCD. Il fallait repérer les 2 héritages (sur captage et sur réservoir). Le sujet lui-même insiste sur les 2 catégories de captages, et l'annexe présente les 2 catégories de réservoirs avec, à chaque fois, des caractéristiques différentes, donc des attributs spécifiques. Les contraintes de partition sont indiscutables dans les 2 cas. Au niveau de la gestion des analyses, cela a dû vous rappeler des choses : on a déjà traité juste cette partie du sujet dans le cours, en abordant la contrainte de partition sur association. Comme cela a été déjà expliqué dans le cours, vous pouvez très bien gérer les analyses avec aussi un héritage. Les 2 solutions sont acceptées. Remarquez la CIF et l'association entre réservoir et captage. L'annexe présente bien cet aspect : chaque réservoir a un captage principal (représenté par le CIF "alimenter") et une liste de captages de secours (représentée par l'association "être secours"). En ce qui concerne les captages de secours d'un réservoir, il faut mémoriser une remarque (mise dans l'association) et le technicien responsable : d'où la cif "nécessiter" qui part de l'association et qui va vers technicien. Cette cif qui part de l'association aurait pu être représentée de plusieurs autres manières : une agrégation, une contrainte d'unicité... En ce qui concerne les débits mensuels des captages, je les aurais plutôt gérés sous forme d'une entité débit avec le mois en identifiant et un lien identifiant vers captage. Si vous avez fait ainsi, c'est très bien. Voici donc la correction officielle suivie des commentaires officiels :

Séquence 6 Autocorrection

Page 215

8 2955 TG PA 00

Bloc 1 : CAPTAGE-POMPAGE-FORAGE Bloc 2 : RESERVOIR-ENTERRE-AERIEN-ALIMENTER Bloc 3 : POSSEDER-MOIS Bloc 4 : ETRE SECOURS-NECESSITER-TECHNICIEN Bloc 5 : ANALYSE-EFFECTUER_1-EFFECTUER_2-RELEVER-SUBSTANCE Bloc 2 : Le groupe de surpression peut apparaître sous forme d'entité, avec un numéro et un débit maximum : il peut être relié à l'entité ENTERRE par une association avec cardinalité 0,n s'il est vu ici comme un type de groupe ou avec cardinalité 1,1 s'il est vu comme groupe. Bloc 5 : On acceptera la présence de 2 propriétés PrésenceBactérieEC (type "Escherichia Coli") et PrésenceEntérocoque dans l'entité ANALYSE. On pourra trouver 2 interprétations d'une analyse : une analyse pour une seule substance, ou une analyse pour plusieurs substances, donc les 2 solutions suivantes sont acceptables : La propriété quantité de l'association Relever peut se trouver dans l'entité ANALYSE avec une cardinalité 1,1 côté ANALYSE.

Séquence 6 Autocorrection

Page 216

On peut aussi trouver deux associations ternaires ANALYSE porteuses d'une propriété quantité entre les entités CAPTAGE, SUBSTANCE et DATE, respectivement RESERVOIR, SUBSTANCE et DATE. On acceptera une spécialisation d'ANALYSE en ANALYSE_CAPTAGE et ANALYSE_ RESERVOIR avec une contrainte de partition : on aura alors la cardinalité 1,1 respectivement sur les associations EFFECTUER. D'autres formalismes (agrégation d'association, entité agrégative, ternaire avec contrainte d'unicité) peuvent remplacer l'association d'association Nécessiter. Question 2 Cette question se situe dans un autre dossier, qui traite de la partie SQL. Cependant, comme il est demandé de réaliser un SCD à partir de relations et que des liens identifiants doivent être repérés, j'ai trouvé intéressant de laisser la question. Avez-vous vu les liens identifiants ? C'est effectivement important que vous sachiez les repérer. En ce qui concerne RELEVE, les clés primaires et étrangères n'étaient pas précisées mais des explications permettaient de les imaginer sans ambiguïté.

8 2955 TG PA 00

Exercice 14 Voilà une autre variante de sujet. Vous avez, comme d'habitude, une SCD à construire, cependant une partie des relations est donnée. Puis il est demandé dans un second temps de placer explicitement une contrainte. Question 1 Pour ce sujet plus complexe, faisons une analyse détaillée du sujet, paragraphe par paragraphe. Tout ce qui est avant "Annexes à utiliser" n'est qu'une introduction à l'étude de cas complète. Il n'y a rien à modéliser mais cela permet d'avoir une idée du contexte de l'étude. "Sur le site intranet, il est actuellement possible de visualiser les bulletins d'inscription au format PDF et de les imprimer (annexes 2a et 2b). Une fois complétés, ces bulletins d’inscription sont envoyés par courrier au CE pour traitement." Cette première partie incite à aller voir les annexes en question. C'est peut-être un peu tôt pour les traiter, cependant elles apportent beaucoup d'informations. On remarque par exemple qu'il y a 2 types de séjours (thématiques et linguistiques). Pour chaque demande, il y a une liste d'informations sur l'enfant (nom, prénom, date de naissance et sexe) ainsi que des informations sur le parent salarié (nom, prénom, adresse, tel, mél). À chaque demande il y a une ville de départ choisie, la référence de la demande, la date. Quelles sont les différences entre ces 2 types de demandes ? Les demandes thématiques peuvent porter sur 1 à 3 séjour(s) alors que les demandes linguistiques ne peuvent porter que sur un séjour. Cette partie donne lieu, dans le schéma, à la création des entités Demande, Enfant et Salarié ainsi que les liens qui les unissent. Les associations DemandeL, DemandeT et Retenir sont aussi issues de cette partie. Cependant on imagine que la suite du sujet va apporter des précisions complémentaires.

Séquence 6 Autocorrection

Page 217

"L'objectif de M. Latin est de mettre en ligne sur l'intranet une application permettant aux salariés de l'entreprise d'enregistrer directement leurs réservations de séjours. Il faut donc compléter l'actuelle base de données (annexe 1)." Dans ce sujet, on vous donne le début de la construction du schéma sous forme de relations. Il fallait donc commencer par cela. De plus, dans l'annexe, sans vous donner les relations correspondantes, on vous dit très clairement de faire un héritage sur Séjour : point qui paraissait déjà évident avec l'étude des 2 autres annexes. Précisions concernant les séjours • Chaque séjour est destiné à une tranche d’âge (code, âge minimum et âge maximum). • Chaque séjour thématique propose aux participants un certain nombre d’activités. • Chaque séjour linguistique peut comprendre des excursions. Il propose dans tous les cas un perfectionnement en langue qui peut prendre une des formes suivantes : cours particuliers, stage intensif, préparation examen…" Le premier point incite à la création d'une entité Tranche pour avoir l'âge min et max, et d'une CIF de Séjour vers Tranche. Le second point demande la création d'une entité Activité et d'une association entre Sejour thématique (et non Séjour) et Activité. Le troisième point doit vous faire modifier votre schéma : d'après les relations, vous aviez dû faire un lien identifiant entre Excursion et Séjour. En fait le lien identifiant ne va pas vers Sejour mais vers Séjour Linguistique. Avec ce troisième point, il fallait

8 2955 TG PA 00

aussi gérer une cif vers une entité Perfectionnement pour savoir quel type de perfectionnement était proposé. Modalités d'inscription d'un enfant L’inscription d’un enfant à un séjour se fait par l’intermédiaire d’une demande d’inscription (annexes 2a et 2b). On souhaite conserver l'historique des demandes pour l’année en cours. En début d’année, le catalogue des séjours est actualisé (dates et prix des séjours), les demandes de l’année écoulée sont supprimées." Les annexes ont déjà été analysées plus haut. Les autres informations (date, prix) sont déjà présentes dans le schéma. "L'état d'une demande doit être enregistré : à traiter, en cours, satisfaite, non satisfaite." Vous avez peut-être fait une entité Etat plutôt que de mettre juste un attribut état dans Demande : c'est plutôt une bonne idée. • "> Demande d'inscription pour un séjour thématique Pour chaque demande concernant un séjour thématique, il est possible de rete-nir jusqu'à trois séjours, numérotés de 1 à 3, par ordre de préférence. Dans le cas où le premier séjour est complet, on passe au second, dans le cas où le second est complet, au troisième. Le séjour retenu (parmi les trois choix possibles) doit être mémorisé lorsque la demande est satisfaite."

Séquence 6 Autocorrection

Page 218

Cela a déjà été traité plus haut (ce sont les fameuses annexes 2a et 2b), cependant on peut apporter une petite précision : cette histoire d'ordre de la demande vous a peut-être incité à faire un lien identifiant. Donc, à la place de l'association DemanderT, il est possible de faire une entité DemandeT avec un numéro d'ordre en identifiant et un lien identifiant sur Demande. Il reste alors à faire une cif de DemandeT vers Séjour Thématique pour connaître le séjour thématique concerné. Cette solution me plaît bien car elle force à numéroter les demandes. "L'enfant doit choisir l'activité qu'il souhaite pratiquer parmi les activités proposées pour chaque séjour." Cela se traduit par l'ajout de la cif de DemanderT vers Activité. • "> Demande d'inscription pour un séjour linguistique Dans ce type de demande, on ne peut choisir qu'un seul séjour." Il n'y a rien de particulier à faire : la cif entre demande et séjour linguistique est déjà présente. Vous avez peut-être traité les demandes en faisant un héritage : ce n'est pas faux mais cela alourdit le schéma en ajoutant des entités inutilement. Par contre, vous avez peut-être ajouté plusieurs contraintes spontanément, et vous avez eu raison ! Une de ces contraintes est explicitement demandée dans la question suivante. Une autre est aussi présentée dans la correction officielle de la question suivante (heureusement, car elle était très évidente : j'y reviendrai dans la deuxième question). On pouvait aussi ajouter une inclusion entre Retenir et DemanderT. Voici la correction officielle de cette première question, suivie des remarques officielles :

8 2955 TG PA 00

Séquence 6 Autocorrection

Page 219

Remarques Il est possible de spécialiser les demandes en fonction du type de séjour choisi. Un enfant peut être relié à deux salariés. On acceptera que les informations concernant l’enfant soient intégrées à la demande.

8 2955 TG PA 00

Question 2 "Toute demande concerne un ou plusieurs séjours thématiques ou (exclusif) un séjour linguistique." C'était une contrainte de partition entre DemanderT et DemanderL (soit l'un, soit l'autre et forcément l'un ou l'autre). Le pivot n'est pas représenté ici, mais il est forcément sur Demande. Le pivot est donc implicite puisqu'il n'y a qu'une seule possibilité (il n'est pas obligatoire de le mettre).

La correction officielle propose une autre contrainte non exigée mais relativement évidente : "Contrainte non exigée : on ne peut demander une activité que si elle est proposée dans le séjour thématique."

Séquence 6 Autocorrection

Page 220

J'espère que vous aviez vu cette contrainte...

Exercice 15 Voilà un sujet, pas forcément très long, mais qui comporte une annexe vraiment difficile à décrypter. D'autant plus que vous n'aviez pas droit à la calculatrice pendant l'examen. Les calculs ne sont pas difficiles, mais ils sont nombreux, interdépendants et n'apparaissent pas spontanément. Ce sujet comporte aussi une longue introduction pour présenter le contexte. Il faut dire que le contexte est lui aussi, assez complexe à comprendre. D'une manière générale, on pourrait croire que l'on est favorisé lorsqu'on a des connaissances préalables sur le contexte présenté. Ce n'est pas forcément le cas car on risque de se laisser influencer par ses propres connaissances alors qu'il faut scrupuleusement respecter le sujet (qui souvent se permet des libertés par rapport à la réalité).

8 2955 TG PA 00

Faisons une analyse détaillée du texte : "Chaque exploitation est composée de plusieurs îlots." Cette partie pousse à faire une entité Exploitation et, a priori, une entité îlot pourquoi pas numérotée par Exploitation (lien identifiant). "Un îlot est un regroupement de parcelles contiguës, limité par des éléments facilement repérables et permanents (comme un chemin, une route, un ruisseau…) et stable d'une année culturale sur l'autre. Le découpage d'un îlot en parcelles est variable d'une année culturale à l'autre, en fonction des mises en cultures envisagées." Cette partie est une des plus intéressantes et des plus complexes du sujet. Les images qui suivent dans le sujet permettent de mieux comprendre. L'annexe conforte aussi dans le principe de numérotation des parcelles : une parcelle change chaque année, tout en étant numérotée par îlot. Il fallait gérer un double lien identifiant sur la parcelle. Si vous l'avez vu, bravo. "Pour une exploitation, on mémorise un code exploitation et les coordonnées de l’exploitant." Ces informations permettent de compléter l'entité Exploitation. Si vous avez fait en plus une entité Exploitant, pourquoi pas. "La collecte des informations pour une exploitation donnée s’effectuait jusqu’à présent sur un document papier appelé cahier d’épandage (cf. annexe 1)..." L'analyse détaillée de l'annexe 1 donne énormément d'informations. Elles sont en partie rappelées dans la suite du texte. En résumé, il fallait comprendre que les parcelles subissent des épandages numérotés par parcelle (lien identifiant). Chaque épandage utilise un produit azoté qui peut être organique ou minéral. Pour les produits minéraux, il faut mémoriser la teneur en azote estimée (car celle-ci ne peut être calculée !). Si vous n'avez pas fait l'entité fille produit organique, ce n'est pas faux car la cif entre épandage organique et produit organique n'est pas nécessaire. L'annexe montre bien la différence entre les 2 types d'épandages et le fait que pour les épandages organiques, plusieurs informations supplémentaires sont à mémoriser (origine, délai d'enfouissement, traitement anti-odeur, teneur en azote calculée). Toutes les autres données du tableau sont interdépendantes et donc calculées.

Séquence 6 Autocorrection

Page 221

L'analyse de l'annexe 1 est complexe : c'est même certainement l'annexe la plus complexe qui ait été proposée dans un sujet officiel. Vous avez cependant le temps de faire une analyse détaillée pour éviter de passer à côté de certaines informations. En fait, toutes les informations sont utiles. Pour traiter ce genre d'annexe, n'hésitez pas à utiliser un surligneur pour vous rappeler des informations que vous avez déjà traitées dans votre SCD. Il n'y avait pas de contrainte sur association dans ce sujet, ni de contrainte sur héritage (excepté la contrainte de partition si vous avez gardé produit organique). Les héritages et les liens identifiants étaient cependant très attendus. Vous verrez dans la correction officielle qu'une seconde solution est proposée pour la gestion des épandages. Personnellement je préfère la première, plus explicite (sans l'héritage sur produit organique qui me semble inutile). C'est donc au final, un sujet d'un certain niveau de complexité.

8 2955 TG PA 00

Voici la correction officielle proposée, suivie des commentaires officiels :

Séquence 6 Autocorrection

Page 222

Ce schéma constitue une solution possible de modélisation : toute autre représentation respectant le sens sera acceptée. L'historisation des parcelles peut être modélisée par une agrégation entre les entités "Ilot" et "Année". L'association "utiliser" peut être un sous-type de l'association "de". Le schéma suivant (extrait) illustre une solution à base d'associations :

8 2955 TG PA 00

Exercice 16 Ce sujet est long, cependant il ne comporte aucune annexe. Les informations et des tableaux d'exemples sont directement intégrés dans le sujet. Le schéma qui en résulte est assez volumineux et contient de nombreuses notions qu'il fallait voir : liens identifiants, héritage avec contrainte, contrainte d'inclusion à portée multiple, et même une association réflexive. Voici l'analyse détaillée du sujet. Gestion des clients "Les clients de SynapsInfo sont des sociétés, répertoriées et classées par activité. Un client appartient à un seul secteur d’activité. Par exemple le client "BPN" appartient au secteur "Banque et Finances". On conserve le code, la raison sociale et l’adresse de chaque client. Les clients possèdent un ou plusieurs sites localisés dans des lieux géographiquement différents. Un site est caractérisé par des informations précisant sa localisation (nom du site, adresse du site) et le nom du référent opérationnel. Un numéro séquentiel permet de distinguer les différents sites d’un même client." Ce paragraphe sur les clients permet de créer l'entité Client, la cif vers une entité Secteur d'activité ainsi que l'entité Site en la numérotant par client. Les informations pour remplir les entités sont explicitement données. Gestion des salariés "Parmi les employés de la société SynapsInfo, on distingue deux catégories de salariés :"

Séquence 6

Même si ce n'est pas encore une certitude, on se doute qu'il va y avoir un héritage sur Salarié.

Autocorrection

Les salariés chargés de l’activité commerciale

Page 223

"Les commerciaux démarchent et négocient les contrats de prestation auprès des entreprises clientes. Un secteur d’activité peut être prospecté par plusieurs commerciaux, mais chaque commercial est spécialisé dans un secteur d’activité. Par exemple "Loïc Morel" prospecte le secteur d’activité "Banque et Finances". Pour chaque commercial, on conserve l’objectif de ventes et le chiffre d’affaires réalisés chaque année. On mémorise également leurs coordonnées téléphoniques, fixe et portable." Là c'est certain : il y a bien héritage. Plusieurs informations sont spécifiques aux commerciaux. Il faut une CIF vers secteur d'activité (pour avoir la spécialité du commercial). Il faut aussi l'historique annuel des objectifs de vente et du chiffre d'affaire réalisé : d'où l'association Réaliser, que j'aurais personnellement plutôt faite sous forme d'entité faible, avec année en clé primaire (pour éviter l'entité temporelle). On se doute aussi qu'il va y avoir une cif de contrat vers commercial mais pour le moment les contrats ne sont pas créés. Les salariés chargés des interventions chez les clients "Chaque intervenant est décrit par son niveau d’études et sa maîtrise de la langue anglaise. Il est qualifié pour intervenir sur un ou plusieurs domaines techniques. Ces domaines sont regroupés par famille technique. Le prix de journée d’un intervenant pour chaque domaine technique varie en fonction des qualifications mises en œuvre."

8 2955 TG PA 00

Voici l'autre sous-type sur Salarié : les intervenants. Il faut mémoriser le niveau d'étude et le niveau en anglais : si vous avez fait des entités supplémentaires et des cif vers ces entités, c'est tout à fait juste. On peut effectivement imaginer une liste de niveaux d'études et à chaque fois une sélection d'un des éléments de cette liste. Idem pour le niveau en anglais. Pour avoir les qualifications dans plusieurs domaines, il faut créer l'entité Domaine et faire une association entre les 2. L'association porte le prix journalier (qui dépend du salarié et de la qualification dans un domaine). Les domaines sont classés par famille : il faut une cif de Domaine vers Famille (qu'il faut créer). Un tableau exemple présenté à la suite de ces explications vient confirmer ce qui a été analysé. "Un domaine technique peut couvrir plusieurs domaines techniques." Une association réflexive sur Domaine ! "Un intervenant maîtrisant le domaine technique « Développement J2EE » ou « Développement middleWare » pourra donc être sollicité sur des interventions relevant du domaine technique "Développement JDBC "." C'est assez tordu car cette phrase va être à l'origine de la création de la contrainte d'inclusion. Mais pour le moment vous ne pouvez pas la créer puisque vous n'avez pas encore abordé les interventions... Cela suppose qu'il faudra revenir sur ce point plus tard. "La couverture d’un domaine par un autre domaine doit être mémorisée." Remarque inutile, juste pour confirmer qu'il faut bien créer l'association réflexive. Séquence 6 Autocorrection

Page 224

Gestion des contrats "La société SynapsInfo crée un contrat correspondant à la réalisation de prestations informatiques à la demande de l’un des sites d’une entreprise cliente. Chaque contrat est suivi par un commercial de la société SynapsInfo et placé sous la responsabilité d’un intervenant. À la négociation du contrat, le commercial fixe une enveloppe financière et un nombre de jours de prestations." C'est la création de l'entité Contrat, avec une cif vers Site (pour avoir le site demandeur), une cif vers Commercial et une cif vers Intervenant. Même si c'est le commercial qui décide, puisqu'il n'y a qu'un seul commercial par contrat, l'enveloppe financière et le nombre de jours de prestations sont directement placés dans l'enti-té contrat. "Chaque contrat est rattaché au site sur lequel seront réalisées les interventions." Il n'y a rien à faire de spécial : les interventions seront de toute évidence rattachées à un contrat donc forcément au site du contrat. Les exemples qui suivent permettent de confirmer les informations précédentes et de remplir l'entité Contrat : date du contrat, intitulé, date de début et description. Gestion des interventions "Chaque contrat donne lieu à une ou plusieurs interventions relevant chacune d’un domaine technique. La liste des interventions est négociée par le commercial à la signature du contrat. Il négocie également le prix de journée contractuel pour chaque intervention. " C'est le moment de créer l'entité Intervention, avec un lien identifiant sur Contrat (confirmé par l'exemple du tableau, où les interventions du contrat 1287 sont numérotées 12871, 12872, 12873...). Le tableau donne aussi les autres informations à mettre dans intervention ainsi que la CIF vers le domaine technique. Encore une fois, ce n'est pas parce que c'est le commercial "qui négocie" qu'il faut pour autant

8 2955 TG PA 00

mettre les informations dans commercial ! Ces informations ne concernent que l'intervention (qui de toute façon n'est reliée qu'à un seul commercial). "Une intervention est identifiée par un numéro d’ordre associé au numéro de contrat Dans le cas où vous n'auriez pas vu le lien identifiant... "Elle peut être dans l’état "À faire", "Planifiée", "En cours", "Interrompue", "Annulée", "Terminée", "Facturée" ou "Archivée"." On vous incite à faire une entité Etat et une CIF d'Intervention vers Etat. "La phase de la planification consiste à affecter un ou plusieurs intervenants à la réalisation de chaque intervention. Pour chaque intervention planifiée, on note la date réelle de début d’intervention au démarrage de celle-ci ainsi que la date réelle de fin, après réalisation de l’intervention." Il faut créer une association entre Intervention et Intervenant. Les autres informations sont à mettre dans Intervention. "Pour permettre de suivre la rentabilité de chaque intervention, on notera la durée d’affectation de chaque salarié concerné. " La durée d'affectation concerne un salarié pour une intervention : l'information doit donc être mise dans l'association. "Afin d’éviter des affectations incohérentes pour chaque intervention, il est important de prévoir des intervenants compétents dans le domaine technique correspondant." C'est un petit rappel pour se souvenir de faire la contrainte d'inclusion qui avait été annoncée plus haut. Au final, même si le sujet paraît long et le SCD conséquent, les explications sont très claires et globalement il n'y a pas de réelles difficultés. La contrainte d'inclusion était assez lourdement évaluée : ce qui pose tout de même un réel problème. En effet, si vous avez fait des erreurs de conception à cet endroit du schéma, vous ne pouvez pas placer la contrainte.

Séquence 6 Autocorrection

Page 225

8 2955 TG PA 00

Voici la correction et les commentaires officiels :

Séquence 6 Autocorrection

Page 226

Remarques Concernant l’association Réaliser, on peut envisager une solution utilisant une entité faible identifiée relativement par la donnée an. On acceptera la contrainte de partition + ou XT pour l'héritage.

Exercice 17 Le sujet est assez long et comporte aussi des annexes. La particularité de ce sujet intervient dans sa deuxième question où un extrait de schéma est présenté et doit être complété avec des contraintes. L'avantage de ce type de question est que l'on peut directement évaluer les capacités de l'étudiant à placer une contrainte : en effet, dans le schéma d'origine, si l'étudiant a fait des erreurs de modélisation, il peut parfois être bloqué pour placer des contraintes éventuelles.

8 2955 TG PA 00

Question 1 On retrouve dans le premier schéma les grands classiques : lien identifiant et héritage. Voici l'analyse détaillée du sujet : "Parmi les prêts accordés par CredAuto, certains font l'objet d'échéances impayées. Lorsque le service « Suivi des prêts » constate le non-paiement d’une échéance, il transmet le dossier du « mauvais » payeur au responsable du service « Contentieux ». Remarque : Par souci de simplification, on admettra qu’une échéance ne fait jamais l’objet d’un règlement partiel. Pour chaque échéance impayée, une lettre de relance est envoyée à l’emprunteur. Au bout de trois lettres de relance restées sans effet, le dossier de prêt est envoyé au bureau « Recouvrement amiable » dépendant du service « Contentieux »." Voilà une partie qui ne sert à rien excepté expliquer le contexte : c'est assez troublant car on nous dit déjà plusieurs choses mais malgré tout il ne faut rien modéliser car seules les données gérées par le service Contentieux sont à modéliser. "L’objectif des intervenants du bureau « Recouvrement amiable » est d’éviter une procédure judiciaire et la saisie du véhicule. Si cela est possible, il est toujours préfé-rable de trouver une solution concertée avec l’emprunteur pour obtenir le rem-boursement effectif du prêt. Dans ce but, le bureau « Recouvrement amiable » désigne un intervenant et lui adresse un ordre de mission (annexe 2A) sur lequel se trouvent un récapitulatif des éléments du contrat, les dates des trois dernières échéances impayées ainsi qu’un commentaire destiné à l’intervenant. Si l’ordre de mission concerne un contrat pour lequel il y a déjà eu un réaménagement du prêt, les renseignements concernant le dernier avenant sont indiqués sur l'ordre de mission." Cette partie incite à l'analyse de l'annexe 2A et permet de commencer à construire les entités Intervenant, OrdreMission, Contrat, Véhicule et Emprunteur ainsi que les liens. Si vous n'avez pas fait d'entité Vehicule et que vous avez tout mis dans Contrat, ce n'est pas faux. À ce niveau du sujet, on ne sait pas encore que Emprunteur sera une entité fille. L'historique des échéances impayées, représenté ici par IncidentContrat, pouvait être fait par une entité faible (et la date en clé primaire).

Séquence 6 Autocorrection

Page 227

"L’intervenant du bureau « Recouvrement amiable » doit disposer des documents relatifs à l’ensemble du dossier : • le contrat de prêt et les avenants éventuels ; • la liste des incidents de paiement (dates des échéances non payées) ; • les différents courriers échangés avec l’emprunteur." Déjà traité... "L’intervenant prend alors contact par téléphone avec l’emprunteur. Si, lors de l’un des rendez-vous obtenus par l’intervenant, le client régularise les échéances impayées, l’ordre de mission est alors clos." Il suffit d'enregistrer la date de clôture. "Dans le cas contraire, l’intervenant fait une proposition de réaménagement du prêt à l’emprunteur. Le montant des échéances est alors revu à la baisse et la durée du prêt allongée. L’intervenant interroge une application du service « Suivi des prêts » qui recalcule le nouveau montant de l’échéance en fonction de la nouvelle durée et du taux du prêt. Un avenant au contrat est alors signé (annexe 2B). "

8 2955 TG PA 00

Cette partie et l'annexe pousse à la création de l'Entité Avenant, très clairement numérotée en fonction du contrat (on le voit dans l'annexe). L'annexe montre que plusieurs personnes peuvent se porter caution : on a alors envie de faire une entité Caution portant les informations des personnes, et une association entre Avenant et Caution pour porter le rang de la caution. Vous pouvez aussi le faire sous forme d'entité faible sur Avenant avec le rang en clé primaire et une cif vers Caution. "À l’origine d’un prêt, CredAuto n’exige jamais l’appui d’un tiers se portant caution de l’emprunteur. Mais, lors d’un réaménagement, l’intervenant du bureau « Recouvrement amiable » peut estimer que cette garantie est devenue indispensable. Il demande alors à l’emprunteur de disposer d’une ou plusieurs cautions. Une caution est une personne solidaire amenée à honorer les échéances de l’emprunteur si ce dernier ne remplit pas ses obligations." Rien de plus... "Toutes les personnes concernées (intervenant, emprunteur, une ou plusieurs cautions) sont obligatoirement signataires de l’avenant. Le nombre des cautions n’est pas limité. Il est nécessaire de distinguer pour quel avenant la personne se porte caution et le rang auquel elle se trouve. Le rang indique l’ordre dans lequel les cautions seront sollicitées si l’emprunteur ne remplit pas ses obligations. Après signature de l’avenant par toutes les parties prenantes, l’ordre de mission est alors clos. " Ne mémorisez pas les signatures ! Sinon, toujours rien de plus... "Suite à un premier réaménagement du prêt, il arrive que celui-ci fasse l’objet de nouveaux impayés. Séquence 6 Autocorrection

Page 228

Le responsable du service « Contentieux » peut alors confier le dossier à un autre intervenant. Dans le cas où un nouvel avenant est négocié, on admettra que l'emprunteur puisse faire appel à de nouvelles cautions, autres que celles désignées lors du précédent réaménagement. On admettra aussi qu’une caution intervenant dans un avenant n’intervienne pas forcément dans un avenant ultérieur au même contrat ou qu’elle puisse intervenir à un rang différent de l’avenant précédent." Toujours rien à faire car l'intervenant est déjà rattaché à l'ordre de mission et pas au contrat. En ce qui concerne les cautions, elles sont déjà rattachées à l'avenant et pas au contrat, donc elles peuvent changer d'un avenant à l'autre. "Remarque : Chaque acteur est référencé de manière unique. Il peut jouer le rôle d’emprunteur dans un ou plusieurs contrats et le rôle de caution dans d'autres contrats" C'est là que vous faites l'héritage ! "Si aucune solution amiable n’est trouvée, l’ensemble du dossier est transmis au service « Contentieux ». L’ordre de mission est alors clos." On a déjà la date de clôture. Le reste du sujet précise les points souhaités : il suffit de vérifier que le SCD répond bien à toutes les attentes. Il y a juste l'aspect de la numérisation et de la conservation des documents qui n'est pas gérée. Il faut donc créer une entité DocumentNumérisé et la rattacher par une CIF (ou, mieux encore, un lien identifiant) à contrat.

8 2955 TG PA 00

Voici la correction et les commentaires officiels :

Séquence 6 Autocorrection

Page 229

(1) Une propriété mensualité peut figurer dans CONTRAT même si elle peut être calculée à partir des propriétés montantPrêt, tauxPrêt et duréeInitiale. Idem pour une propriété montantÉchéanceAvenant dans AVENANT. Les propriétés jourPrélévement et jourPrévuAvenant peuvent ne pas figurer sur le schéma car elles peuvent être calculées à partir respectivement des propriétés datePremièreÉchéance et dateDébutAvenant. On acceptera la présence des propriétés immatriculation, typeAchat, soit dans l’entité VEHICULE, soit dans l’entité CONTRAT. On acceptera une solution basée sur la notion d’échéancier ou d'engagement (jour prélèvement, montant, durée, date début), considérant qu’un avenant constitue un nouvel échéancier du contrat. Une solution consistant à généraliser les entités CONTRAT et AVENANT en une entité DOSSIER (identifiée par une propriété spécifique) est acceptée mais l'identification relative de l'entité AVENANT n'est pas possible, une association entre les entités CONTRAT et AVENANT est nécessaire, et les entités CONTRAT et AVENANT ne doivent pas avoir d'identifiant. (2) On acceptera les cardinalités 1,n sur l’association « Rattacher à » côté entité DOCUMENT NUMERISE : en effet, on peut considérer qu’un même document numérisé soit repris pour des contrats différents s’ils concernent le même emprunteur.

8 2955 TG PA 00

(3) Une contrainte peut être mentionnée sur le schéma : à une date donnée, on ne peut pas connaître à la fois un « incident contrat » et un « incident avenant » qui concerne ce contrat. La mention de cette contrainte ne sera pas exigée. La solution liant uniquement DATE et CONTRAT par une association Incident sera admise, ainsi que la solution reposant sur deux entités INCIDENT CONTRAT et INCIDENT AVENANT, identifiées relativement à CONTRAT et AVENANT. (4) En choisissant une représentation basée sur une association, on garantit l’unicité du couple AVENANT-CAUTION. Mais il faudrait mentionner par ailleurs la contrainte qui concerne le rang : dans un avenant, le rang est unique, il ne saurait être partagé par plusieurs cautions liées au même avenant. La solution suivante sera admise : ici, l’unicité du rang dans un avenant est garantie. Mais il faudrait mentionner par ailleurs la contrainte qui concerne la caution : une caution ne peut intervenir plusieurs fois dans un même avenant.

Séquence 6 Autocorrection

Page 230

Dans les deux cas, la mention de la contrainte ne sera pas exigée. (5) On ne pénalisera pas le candidat qui aura présenté une association entre ORDRE MISSION et AVENANT. La mission concerne avant tout un contrat et précède l’avenant (c’est le rôle de la mission que de définir s’il doit y avoir un avenant et quelles en seront les modalités). Question 2 Il faut placer 2 contraintes sur un schéma existant. La première est une contrainte de partition (l'un ou l'autre, pas les 2 et pas autre chose) et la seconde est une contrainte d'inclusion à portée multiple.

8 2955 TG PA 00

Séquence 6 Autocorrection

Page 231

8 2955 TG PA 00

4. MCD ou Diagramme de classes ? Exercice 1 Voici le diagramme de classes correspondant au MCD présenté :

Séquence 6 Autocorrection

Page 232

Le modèle comportait : • des entités qui ont été traduites en classes ; • des CIF qui ont été traduites en liens avec une multiplicité de 1 (faites bien attention à la position du 1) ; • un héritage qui a été traduit en héritage ; • une association porteuse qui a été traduite en classe-association ; • un lien identifiant qui a été traduit en lien de composition.

8 2955 TG PA 00

Exercice 2 Voici le diagramme de classes correspondant au MCD présenté :

Séquence 6

Ce second exercice est totalement similaire au premier. C'était l'occasion pour vous de tester que les notions du premier exercice étaient acquises. Le modèle comportait : • des entités qui ont été traduites en classes ; • des CIF qui ont été traduites en liens avec une multiplicité de 1 (faites bien attention à la position du 1) ; • un héritage qui a été traduit en héritage ; • deux associations porteuses qui ont été traduites en classes-associations ; • un lien identifiant qui a été traduit en lien de composition.

Autocorrection

Page 233

8 2955 TG PA 00

Exercice 3 Question 1 a) Il existe plusieurs plats dans chaque catégorie. VRAI : il faut regarder le lien entre les classes PLAT et CATEGORIE et surtout la multiplicité qui est du côté de PLAT (rappelez vous que les multiplicités sont inversées par rapport aux cardinalités du MCD). b) Une famille est numérotée par rapport à la catégorie à laquelle elle est rattachée. FAUX : c'est le contraire. Le lien de composition est du côté de FAMILLE, donc une famille possède plusieurs catégories (une collection) et ces catégories sont numérotées par rapport aux familles. c) Un menu est considéré comme un produit. VRAI : la classe MENU est une classe fille de PRODUIT. d) La propriété "quantité" représente la quantité de plats qui ont le même ingrédient. FAUX : cette propriété est dans la classe-association INGREDIENT_PLAT qui est entre PLAT et INGREDIENT. Donc cette propriété concerne un plat et un ingrédient. En clair, c'est la quantité d'un ingrédient dans un plat. e) Il existe des produits autres que des menus ou des plats. VRAI : la contrainte sur l'héritage est une contrainte d'exclusion, donc il existe des produits qui ne sont ni des plats ni des menus (par exemple des boissons). Question 2 Voici le MCD correspondant au diagramme de classes présenté : Séquence 6 Autocorrection

Page 234

Le diagramme de classes comportait : • des classes simples traduites en entités ; • un lien association avec une multiplicité 1, traduit en CIF ; • un lien association avec des multiplicités * des 2 côtés, traduit en association binaire non porteuse ; • une classe-association traduite en association binaire porteuse ; • un lien de composition traduit en lien identifiant ; • un héritage traduit en héritage ; • et enfin une contrainte au niveau de l'héritage dont le nom est explicite.

8 2955 TG PA 00

Exercice 4 Question 1 a) Un bilan concerne une seule mission de contrôle et une mission de contrôle peut avoir plusieurs bilans. FAUX : attention de ne pas tomber dans l'erreur de l'interprétation des multiplicités inversées par rapport aux cardinalités du MCD. Le 1 étant du côté de BILAN, cela signifie qu'une mission de contrôle n'a qu'un bilan, en revanche un bilan peut concerner plusieurs missions de contrôles. b) le lien qui boucle sur PLANETE traduit une association réflexive qui donnera naissance à une table contenant 2 attributs en clé primaire, faisant référence à la même table. VRAI : et d'ailleurs ici, l'absence de mots (rôles) sur le lien empêche de connaître le rôle de ce lien. Du coup, cela pose problème pour la traduction en MCD. c) Le lien de composition entre ET (Extra Terrestre) et SEJOUR montre qu'un ET effectue un seul séjour qui lui appartient. FAUX : c'est le contraire (là encore, il ne faut pas lire à l'envers les multiplicités). Un ET peut effectuer plusieurs séjours, chaque séjour étant lié directement à un seul ET. Le lien de composition traduit le fait que la suppression d'un ET supprimerait tous les séjours qui lui sont associés, car un séjour n'a pas d'existence sans l'ET auquel il est associé. d) Tous les liens entre les classes traduisent des associations qui donneront naissance à des tables dans la base de données. FAUX : ce n'est que le cas pour les liens dont la multiplicité est * des deux côtés. En ce qui concerne les liens dont l'une des multiplicités est 1, la traduction sera sous forme d'une clé étrangère dans la table qui se trouve à l'opposée du 1. e) La classe SANCTION_PRISE est une classe_association qui donnera lieu à la création d'une table dans la base de données. VRAI : la table aura pour clé primaire les attributs correspondants aux identifiants des deux tables associées, et les attributs simples sont les propriétés de la classe.

Séquence 6 Autocorrection

Page 235

8 2955 TG PA 00

Question 2 Voici le MCD correspondant au diagramme de classes présenté :

Séquence 6 Autocorrection

Page 236

Ce deuxième exercice sur le passage du diagramme de classes au MCD était nettement plus complexe, cependant le principe reste le même. Le diagramme de classes comportait : • des classes simples traduites en entités ; • des liens associations avec une multiplicité 1, traduits en CIF ; • des liens associations avec des multiplicités * des 2 côtés, traduits en associations binaires non porteuses (c'est aussi le cas de CONFLIT qui est une association réflexive, dont le nom n'était pas donné au niveau du diagramme de classes, du coup vous avez très bien pu l'interpréter et le nommer autrement) ; • des classes-associations traduites en associations binaires porteuses ; • des liens de composition traduits en liens identifiants ; • des héritages traduits en héritages ; • et enfin des contraintes dont les noms étaient assez explicites. Un petit complément d'information cependant sur les contraintes d'inclusions : la flèche est obligatoire dans un MCD alors qu'elle ne l'est pas dans un diagramme de classes, partant du principe que l'inclusion est sous-entendue.

8 2955 TG PA 00

Exercice 5 L'approche de l'exercice doit se faire finalement avec la même logique que lorsque vous construisez un MCD. Voici l'analyse détaillée du sujet. Le lien de composition sur l'achat de pouvoir était assez clairement présenté : "un joueur ne peut pas passer plusieurs achats du même pouvoir le même jour". Le lien de composition sur COMMANDE était très explicitement demandé : "les commandes sont numérotés séquentiellement par joueur". Il fallait absolument le voir. Les modes de paiement étant utilisés à plusieurs niveaux, il fallait faire une classe pour les recenser et les utiliser. Les incompatibilités entre les pouvoirs sont gérées par une association réflexive : c'est le cas classique des couples d'informations. Il faut réaliser les couples de pouvoirs incompatibles. Il fallait aussi voir l'héritage sur CADEAU car seuls les cadeaux "bouquet" offrent des pouvoirs. Il était inutile de gérer l'autre classe fille. Enfin il restait un point assez complexe : l'utilisation des pouvoirs. Puisque les pouvoirs proviennent de 2 sources (achats et cadeaux), soit il fallait gérer les utilisations restantes à partir de ces deux sources, soit, plus simplement, il suffisait de faire une association entre POUVOIR et JOUEUR. C'est la deuxième solution qui a été choisie ici. Si vous avez opté pour la première solution, il fallait mettre un attribut supplémentaire dans ACHAT_POUVOIR (pour les pouvoirs restants d'un achat) et dans CADEAU_COMMANDE (attribut qui parfois devrait rester vide dans le cas de cadeaux réels). Cette solution était vraiment à éviter car au niveau des traitements, cela complique beaucoup les choses car il faut rechercher tous les achats et cadeaux d'un même pouvoir pour trouver le nombre d'utilisations restantes.

Séquence 6 Autocorrection

Page 237

La quantité dans CADEAU_COMMANDE n'est pas demandée. Elle me paraissait cependant assez logique.

8 2955 TG PA 00

5. La programmation du SGBDR Exercice 1



DECLARE v_monnb INTEGER DEFAULT 5; BEGIN FOR v_compteur IN 1..10 LOOP SELECT v_compteur || ' x ' || v_monnb || ' = ' || v_compteur * v_monnb ; END LOOP; END;

Exercice 2 • Écrire une procédure qui permet d’afficher un caractère un certain nombre de fois. Le caractère et le nombre de fois, sont fournis.

Séquence 6 Autocorrection

Page 238

8 2955 TG PA 00

CREATE PROCEDURE affichecar(i_nombre IN INTEGER, i_car IN VARCHAR) BEGIN FOR v_compteur IN 1..i_nombre LOOP SELECT i_car ; END LOOP; END ;

• Fonction qui retourne le prix à payer en fonction d’un poids fourni : CREATE FUNCTION fraistransport(i_poids IN INTEGER) RETURNS DECIMAL(5,2) DECLARE T1 DECIMAL(5,2) DEFAULT 1.5 ; T2 DECIMAL(5,2) DEFAULT 1.0 ; T3 DECIMAL(5,2) DEFAULT 0.5 ; BEGIN IF (i_poids = 500 AND carealisepourunvendeur(idvendeur) >= 7500 ; Comme dit au début de cet exercice, l'objectif ici était de manipuler les curseurs afin que vous les compreniez et sachiez les interpréter. Mais selon les cas, il est évident qu'il sera plus simple de ne pas les utiliser. Attention toutefois à bien se rappeler que les curseurs deviennent incontournables dès lors que les requêtes retournent de nombreux résultats.

8 2955 TG PA 00

Exercice 5 Le déclencheur permet d’interdire l’ajout d’une pulvérisation à une parcelle qui a déjà fait l’objet d’un traitement en semence. En effet, il est indiqué qu’une pulvérisation ne concerne que des traitements en champ. CREATE TRIGGER trg_insert_Traitement BEFORE INSERT ON Traitement DECLARE nbTrt INTEGER ; BEGIN IF (NEW.typeTraitement = 's') SELECT COUNT(*) INTO nbTrt FROM traitement WHERE traitement.idParcelle = NEW.idParcelle AND typeTraitement = 's' ; IF (nbTrt > 0) BEGIN RAISE EXCEPTION 'Erreur !' ; END IF; END IF; END ; "RAISE EXCEPTION" permet de déclencher l'interruption du trigger en mentionnant le motif entre quotes. Cette interruption étant déclenchée avant ("BEFORE") l'insertion, cela permet d'empêcher réellement l'insertion d'avoir lieu. Séquence 6 Autocorrection

Page 242

• On peut également trouver une solution basée sur une requête SQL "EXISTS": IF ((NEW.typeTraitement = 's') AND (EXISTS (SELECT * FROM traitement WHERE traitement.idParcelle = NEW.idParcelle AND typeTraitement = 's'))) RAISE EXCEPTION 'Erreur !'; END IF ; • Le déclencheur peut être lancé sur un "UPDATE" ; La condition "dosageTraitementSemence IS NOT NULL" peut remplacer la condition "typeTraitement = 's'".

Exercice 6 Il faut écrire un déclencheur (trigger) qui se déclenche sur insertion dans la table PRIXPRODUIT et effectue le travail demandé. Principe de ce trigger (non demandé) : • recherche de la dernière ligne (avec "SELECT COUNT(*)") de la table "prixproduit" pour le produit en question (donc avec "code = NEW.code") • si le nombre retourné est différent de "0" et que la date de fin est à "NULL" alors on effectue un "UPDATE" pour alimenter la date de fin d’application avec SysDate().

8 2955 TG PA 00

Exercice 7 1. L e déclencheur permet de s'assurer que le commercial qui rend visite à un client a bien été affecté au même secteur que le client concerné. 2. L e message "Erreur" peut être remplacé par un message plus explicite : "Impossible d'enregistrer la visite. Tout commercial qui rend visite à un client doit avoir été affecté au même secteur que le client". Il faut ajouter la ligne figurant en caractère gras : DECLARE numrows INTEGER ; NEW désigne ici la ligne de la table VISITE /* instructions du déclencheur */ en cours d'insertion BEGIN SELECT count(*) into numrows FROM AFFECTE A, PROSPECT P WHERE A.codeCommercial = NEW.codeCommercial AND P.code = NEW.codeProspect AND A.codeSecteur = P.codeSecteur AND NEW.date >= A.dateDebut AND NEW.date < dateadd(A.dateDebut,A.dureeAffectation); IF (numrows = 0) THEN /* raise_application_error est une fonction intégrée au SGBDR utilisé qui permet d'une part de générer une erreur de numéro -10000 accompagné d'un message d'erreur et d'autre part d'annuler la mise à jour courante, en l'occurrence ici l'insertion d'une ligne dans la table VISITE */ raise_application_error (-10000, ' Impossible d'enregistrer la visite. Tout commercial qui rend visite à un client doit avoir été affecté au même secteur que le client à la date de la visite') END IF ; END ;

Séquence 6 Autocorrection

Page 243

La présence du nouveau message d'erreur n'était pas exigée.

8 2955 TG PA 00

Exercice 8 La requête déterminant le contenu du curseur "Curs_SousTraitant" était importante pour la suite. C'est elle qui va nous permettre de trouver les charges de travail du matin ("chargeMAT") et de l'après-midi ("chargeAPM") pour un jour précis ("i_dateSaisie" passé en paramètre) et pour un sous-traitant en particulier ("i_nomSaisi"). En s'appuyant sur le sujet, il suffit ensuite d'utiliser les durées maximales (240) pour déterminer les charges de travail restantes. CREATE PROCEDURE edit_EtatSousTraitant (i_nomSaisi IN VAR-CHAR, i_dateSaisie IN DATE) DECLARE -- déclaration du curseur Curs_SousTraitant CURSOR FOR SELECT numero, chargeMAT, chargeAPM FROM PLANNING JOIN CONTRAT USING (numeroContrat = numero) JOIN SOUS_TRAITANT USING (codeSousTraitant = code) AND dateJournee = i_dateSaisie AND nom = i_nomSaisi ORDER BY 1;

Séquence 6 Autocorrection

Page 244

-- déclaration du gestionnaire CONTINUE HANDLER FOR NOT FOUND SET v_curseurvide := TRUE; -- déclaration des variables locales v_curseurvide BOOLEAN DEFAULT FALSE; v_numContrat INTEGER; v_chargeMAT INTEGER; v_chargeAPM INTEGER; v_chargeRestanteMAT INTEGER; v_chargeRestanteAPM INTEGER; BEGIN -- ouverture du curseur OPEN Curs_SousTraitant; -- lecture du premier enregistrement FETCH Curs_SousTraitant INTO v_numContrat, v_chargeMAT, v_chargeAPM; -- impression de l’entête SELECT ' DATE : ', i_dateSaisie; SELECT ' Nom du sous-traitant : ', i_nomSaisi; WHILE (NOT v_curseurvide) DO -- impression du récapitulatif du contrat SELECT ' Contrat No : ', numContrat; SET v_chargeRestanteMAT := 240 - chargeMAT; SET v_chargeRestanteAPM := 240 - chargeAPM; SELECT v_chargeRestanteMAT, v_chargeRestanteAPM; -- lecture de l'enregistrement suivant FETCH Curs_SousTraitant INTO v_numContrat, v_chargeMAT, v_chargeAPM; END WHILE; -- fermeture du curseur CLOSE Curs_SousTraitant; END;

8 2955 TG PA 00