Editions ENI Livres | Vidéos | e-Formations
Exercices
Exercices applicatifs
Ce chapitre va vous permettre de travailler un peu plus avec la méthode Merise.
Les exercices proposés sont résolus et certains points sont expliqués.
Comme toute méthode informatique doit répondre à quelques objectifs principaux, voici les conseils d’usage...
Définissez ce que l’utilisateur final veut informatiser et la faisabilité. Pour bien définir l’expression des besoins de l’utilisateur final la méthodologie Merise vous sera d’une grande aide. En effet, en raison de son caractère graphique et de sa sémantique simple, la méthode Merise peut être comprise par un non-informaticien. Il est plus simple de faire valider un modèle conceptuel des données qu’une prise de notes. L’avantage de faire valider un modèle Merise est de pousser l’utilisateur final à réfléchir à l’ensemble de son système d’information.
Vérifiez la cohérence de la demande. Cela consiste à bien délimiter le périmètre du système d’information et de ses sous-systèmes. Là encore, grâce à ses modèles, Merise permet un découpage fin des règles métier et met en évidence les interactions des traitements.
Structurez les données à informatiser. Bien structurer...
Premier exercice
1. Énoncé
M. Bousquet est un agriculteur. Il vend les lapins, les poules, les dindes, les veaux, les cochons qu’il élève. Selon la saison, il vend aussi des légumes (choux, pommes de terre, carottes...) et des fruits (fraises, poires, pommes...). Il ne fait que de la vente directe.
À la suite de votre discussion, il ressort les informations suivantes :
-
À l’heure actuelle, les ventes sont inscrites sur trois cahiers distincts :
-
un pour les animaux ;
-
un pour les fruits ;
-
un pour les légumes.
-
Tout est vendu au kilo, les animaux sont pesés vivants avant d’être vendus.
M. Bousquet souhaiterait un logiciel simple pour saisir les ventes journalières et éditer un récapitulatif mensuel par type de vente (animaux, légumes et fruits) et par produit (poulets, lapins, poireaux, poires...) pour sa comptabilité.
Travail à faire
-
Créer le modèle conceptuel des données.
-
Concevoir le modèle logique des données.
-
Concevoir le modèle physique (ou relationnel) des données.
2. Solution
a. Le modèle conceptuel des données
Voici un premier modèle conceptuel des données. Attention, il présente des imperfections structurelles qui nuisent à la performance, à la maintenance et à l’intégrité de l’applicatif.
Au premier regard, ce modèle peut sembler cohérent.
Si vous y regardez de plus près et imaginez la structure physique de la table Vendre, vous verriez ceci :
Vendre(#CodeAnimal, #CodeLégumes, #CodeFruits, #DateDeVente, Poids)
Imaginons le fichier :
|
#CodeAnimal |
#CodeLégumes |
#CodeFruits |
#DateDeVente |
Poids |
|
1 |
NULL |
NULL |
06/01/2024 |
2 |
|
2 |
15 |
5 |
06/01/2024 |
6 |
|
|
|
|
|
|
Incohérences
La première ligne présente deux codes NULL. Le fichier risque donc de contenir des cellules vides, ce qui va l’alourdir inutilement.
La deuxième ligne présente un inconvénient majeur. En effet, à quel produit correspond le poids inscrit (6 kilos). Est-ce à l’animal de code 2 ? au légume de code 15 ? au fruit de code 5 ?
Voici un autre modèle optimisé par rapport au précédent :
b. Le modèle logique des données
Voici le modèle logique qui en découle, tel que généré par WinDesign :
c. Le modèle relationnel
Enfin, concevez le modèle relationnel :
Types(Codetype, Désignation)
Produits(CodeProduits, Désignation, Prix_au_kilo, #Codetype)
Date(DateDeVente)
Vendre(#CodeProduits, #DateDeVente, Poids)
La table Types est par exemple :
|
CodeType |
Désignation |
|
1 |
Animaux |
|
2 |
Fruits |
|
3 |
Légumes |
La table Produits pourrait ressembler à ceci :
|
CodeProduits |
Désignation |
Prix_au_Kilo |
#Codetype |
|
1 |
Lapin |
7 |
1 |
|
2 |
Veau |
11 |
1 |
|
3 |
Salade |
1,2 |
3 |
|
4 |
Endives |
11 |
3 |
|
5 |
Pommes |
5 |
2 |
|
6 |
Noisettes sèches |
15 |
2 |
Et la table Vendre :
|
CodeProduits |
DateDeVente |
Poids |
|
1 |
07/01/24 |
2 |
|
1 |
08/01/24 |
1 |
|
6 |
08/01/24 |
0,5 |
|
2 |
08/01/24 |
4 |
Voilà, le modèle devient cohérent. Si vous regardez la première ligne de la table Vendre, vous pouvez voir qu’il a été vendu 2 kilos d’un produit de code 1 (soit un lapin à 7 euros le kilo de CodeType 1, c’est-à-dire Animaux), le 7 janvier 2024.
Le total dû sera calculé, donc il n’est pas nécessaire de le stocker.
Le logiciel développé à la suite de cette analyse présente toutes les informations nécessaires pour pouvoir répondre aux besoins de M. Bousquet.
Deuxième exercice
1. Énoncé
Voici un modèle relationnel décrivant une nomenclature, c’est-à-dire l’ensemble des éléments constitutifs d’un meuble. Le meuble est un ensemble composé de sous-ensembles et de composants divers. Un sous-ensemble est élaboré grâce à un assemblage de composants.
À partir de ce modèle relationnel, il vous est demandé de procéder à du reverse engineering (en français, rétro-ingénierie). C’est-à-dire de remonter jusqu’au modèle conceptuel en passant par le modèle logique des données.
Modèle relationnel
Ensembles(CodeEnsemble, Désignation)
Sous-Ensembles(CodeSousEnsemble, Désignation, Longueur, Largeur, Hauteur, Prix_Unitaire)
Composants(CodeComposant, Désignation, Prix_Unitaire)
LienEnsSE(#CodeEnsemble, #CodeSousEnsemble, Qté)
LienEnsComposant(#CodeEnsemble, #CodeComposant, Qté)
LienSEComposant(#CodeSousEnsemble, #CodeComposant, Qté)
2. Solutions
a. Le modèle logique des données
Voici le modèle logique que l’on peut concevoir à partir du modèle relationnel :
b. Le modèle conceptuel des données
Troisième exercice
1. Énoncé
Comme toutes les personnes de votre village font appel à vos services lorsqu’ils ont un problème informatique, vous êtes sûr de réussir votre vie professionnelle en créant une micro-entreprise d’assistance informatique.
Pour démarrer votre activité, il vous faut un petit logiciel vous permettant de saisir vos interventions pour faciliter la tenue de votre comptabilité.
Ce logiciel permettra la saisie des coordonnées des clients et du matériel sur lequel vous êtes intervenu.
Vous décidez d’appliquer un prix horaire différent selon le type d’intervention (certaines réparations ou manipulations complexes doivent être facturées plus cher).
Pour certaines pannes, vous vendrez le composant neuf. Le logiciel devra donc intégrer la vente de matériel inhérente à la réparation.
Travail à faire
-
Concevoir le dictionnaire des données simplifié.
-
Concevoir le modèle conceptuel des données.
-
Concevoir le modèle logique des données.
-
Concevoir le modèle physique des données.
2. Solution
a. Le dictionnaire des données simplifié
|
Nom de la donnée |
Format |
Longueur |
Type |
|
CodeClient |
Alphanumérique |
15 |
Élémentaire |
|
Nom |
Alphabétique |
30 |
Élémentaire |
|
Prénom |
Alphabétique |
30 |
Élémentaire |
|
Adresse |
Alphabétique |
30 |
Élémentaire |
|
Code Postal |
Alphanumérique |
6 |
Élémentaire |
|
Ville |
Alphabétique |
30 |
Élémentaire |
|
Téléphone |
Alphanumérique |
15 |
Élémentaire |
|
|
Alphanumérique |
30 |
Élémentaire |
|
CodeMatériel |
Alphanumérique |
15 |
Élémentaire |
|
Désignation |
Alphanumérique |
60 |
Élémentaire |
|
Fabricant |
Alphanumérique |
60 |
Élémentaire |
|
Date d’achat |
Date |
|
Élémentaire |
|
NumIntervention |
Alphanumérique |
15 |
Élémentaire |
|
Descriptif Panne |
Alphanumérique |
60 |
Élémentaire |
|
Date d’intervention |
Date |
|
Élémentaire |
|
Temps Passé |
Numérique |
|
Élémentaire |
|
CodeIntervention |
Alphanumérique |
15 |
Élémentaire |
|
Désignation |
Alphanumérique |
60 |
Élémentaire |
|
Prix horaire |
Numérique |
|
Élémentaire |
|
Référence Pièce |
Alphanumérique |
15 |
Élémentaire |
|
Libellé |
Alphanumérique |
60 |
Élémentaire |
|
Prix |
Numérique |
|
Élémentaire |
b. Le modèle conceptuel des données
Un client peut posséder un ou plusieurs matériels. Une intervention concerne un et un seul matériel et un matériel précis peut nécessiter zéro ou plusieurs interventions.
Une pièce détachée (par exemple, un disque dur de référence DD001) peut être utilisée lors d’une intervention dans une quantité précise.
Une intervention est classifiée sous un et un seul type, et à un type d’intervention précis peut correspondre zéro ou plusieurs interventions.
c. Le modèle logique des données
Le modèle logique des données ne présente aucune difficulté. La relation porteuse Utiliser est transformée en entité. Les clés primaires des entités faisant partie de la relation (Pièce et Intervention) sont intégrées et deviennent les nouvelles clés étrangères de la relation Utiliser.
d. Le modèle physique des données
Clients(CodeClient, Nom, Prénom, Adresse, Code Postal, Ville, Téléphone, Mail)
Matériel(CodeMatériel, Désignation, Fabriquant, Date d’achat, #CodeClient)
Pièce(Référence Pièce, Libellé, Prix)
Utiliser(#Référence Pièce, #NumIntervention, Qté)
Intervention(NumIntervention, Descriptif Panne, Date d’intervention, Temps Passé, #CodeIntervention, #CodeMatériel)
Type d’intervention(CodeIntervention, Désignation, Prix Horaire)
Quatrième exercice
1. Énoncé
Un de vos amis qui exerce la profession d’agent immobilier vous demande de réaliser un petit programme.
Il désire un logiciel dans lequel il peut inscrire son fichier de maisons, de propriétaires et de locataires.
Règles de gestion
Une maison appartient à une ou plusieurs personnes.
Une personne peut être propriétaire d’une maison et en louer une autre.
Travail à faire
-
Créer le modèle conceptuel des données.
-
Concevoir le Modèle logique des données.
-
Concevoir le modèle physique des données.
2. Solution
a. Le modèle conceptuel des données
Ici, nous voyons deux relations entre deux entités. Le traitement de ce cas de figure est classique. Les règles indiquées précédemment s’appliquent intégralement.
b. Le modèle logique des données
Voici une représentation WinDesign. Une nouvelle entité est créée et une clé étrangère est glissée dans l’entité Personnes.
c. Le modèle physique des données
Voici le modèle physique des données que l’on peut concevoir à partir du MLD précédent.
Personnes(NumPersonne, Nom, Prénom, #NumMaison)
Maisons(NumMaison, Adresse, Code Postal, Ville)
Posséder(#NumPersonne, #NumMaison)
Cinquième exercice
1. Énoncé
Assur’Auto, comme son nom l’indique, est une société d’assurance spécialisée dans les contrats d’assurance automobile. Elle dispose de plusieurs agences et compte plusieurs employés). Elle assure aussi bien les véhicules de tourisme que les véhicules utilitaires.
Pour assurer un véhicule, son propriétaire, dont on enregistre le nom, le prénom, l’adresse et les coordonnées (téléphone, numéro de fax éventuel, adresse e-mail…), doit fournir au conseiller de l’agence la carte grise du véhicule afin que l’on enregistre son type, sa marque, son numéro d’immatriculation, sa date de mise en circulation et sa puissance fiscale. S’il s’agit d’un véhicule de tourisme, on enregistre aussi le nombre de portes et de passagers autorisés, tandis que s’il s’agit d’un véhicule utilitaire, on enregistre le poids à vide, le poids autorisé en charge, la longueur, la largeur.
Chaque contrat, établi à une certaine date, est référencé par un numéro de contrat et est d’une certaine catégorie : tous risques, au tiers...
Le contrat est attaché à la personne, pas au véhicule : lorsqu’il y a un changement de véhicule...
Sixième exercice
1. Énoncé
L’entreprise XProd fabrique et commercialise divers produits. Ils sont identifiés par une référence propre à XProd et on enregistre une désignation (libellé court), un descriptif (libellé long) et un prix de vente catalogue unitaire hors taxes.
Dans la base de données, XProd gère deux types de produits :
-
Les produits que l’entreprise fabrique pour lesquels elle enregistre le nombre moyen d’heures de main-d’œuvre nécessaires à leur fabrication.
-
Les produits dits « approvisionnés » parce qu’elle ne les fabrique pas : ils sont achetés à un ou plusieurs fournisseurs à un prix d’achat unitaire moyen.
Pour ne pas dépendre d’un fournisseur, pour chaque produit approvisionné, l’entreprise a établi une liste de fournisseurs capables de livrer ce produit. La raison sociale, l’adresse, etc., de chaque fournisseur sont enregistrées. Bien entendu, pour un même produit, chaque fournisseur peut avoir sa propre référence et un prix différent.
Lorsque XProd passe une commande à une certaine date à un fournisseur, elle essaie de grouper plusieurs lignes de commande : une par produit dans une certaine quantité avec sa date de livraison prévue, pour réduire...
Septième exercice
1. Énoncé
Les fédérations de sport proposant des compétitions composées de plusieurs sports ou épreuves, comme le biathlon, le triathlon et autre décathlon, vous ont demandé d’analyser et de développer un logiciel générique pouvant gérer l’organisation de leurs compétitions. Voici quelques éléments vous permettant de commencer l’analyse.
Un sportif s’inscrit à une compétition. Lors de cette inscription, on enregistre son nom, son prénom, son adresse et ses coordonnées téléphoniques, son numéro de fax et son adresse e-mail. On lui attribue un numéro de dossard dans cette compétition, qui servira aussi à retrouver son dossier d’inscription.
Attention : un sportif peut être licencié à la fédération via un club ou pas, les amateurs sont parfois autorisés à concourir. C’est pourquoi pour un sportif licencié, on enregistre bien sûr son numéro de licence et son club, tandis que pour un sportif amateur on exige seulement un certificat médical, nomitatif, daté de moins de trois mois, délivré par un médecin du sport pour des questions d’assurance.
Une compétition a lieu à une certaine date dans une certaine ville et porte éventuellement un libellé comme « Grand Prix de printemps ». Chaque compétition est composée d’un certain nombre d’épreuves effectuées dans un certain ordre : par exemple, 3 km de natation suivis de 50 km de vélo puis de 20 km de course à pied ; ou encore l’escalade d’un mur de niveau 3, suivie d’une randonnée pédestre de 10 km, puis d’un parcours en traîneau tiré par des chiens… Bref, chaque épreuve est d’un certain type et il faut spécifier alors sa distance et les conditions de réalisation.
Travail à faire
Au niveau des données :
-
Créer le dictionnaire des données.
-
Créer le modèle conceptuel des données.
-
Concevoir le modèle logique des données.
-
Concevoir le modèle relationnel des données.
Au niveau des traitements :
-
Créer le modèle de contexte concernant l’inscription d’un sportif licencié d’un club à une compétition.
Lors de l’inscription, un stand est mis en place avec plusieurs bénévoles. L’un d’eux est chargé de vérifier la licence et de réaliser la préinscription du sportif sur la compétition. Il communique les frais d’inscription au sportif. Une fois les frais d’inscription connus, le sportif les règle à une deuxième personne chargée de la comptabilité qui lui remet une facture acquittée. Avec cette facture acquittée, le sportif se déplace jusqu’à un troisième bénévole qui lui remet son numéro de dossard et transmet au premier bénévole un bon de validation.
-
Créer le modèle de flux conceptuel de niveau 1, représentant le processus de validation de l’inscription à une compétition.
-
Créer le modèle organisationnel des traitements.
-
Créer une requête SQL qui liste l’ensemble des sportifs habitant Perpignan.
2. Solution
a. Le dictionnaire des données
Voici un dictionnaire des données très simplifié :
|
Nom de la donnée |
Format |
Longueur |
|
Nom du sportif |
Alphabétique |
30 |
|
Prénom du sportif |
Alphabétique |
20 |
|
Adresse |
Alphanumérique |
60 |
|
Code postal |
Alphanumérique |
5 |
|
Ville |
Alphanumérique |
60 |
|
Téléphone |
Alphanumérique |
15 |
|
Fax |
Alphanumérique |
15 |
|
|
Alphanumérique |
40 |
|
Numéro de licence |
Alphanumérique |
10 |
|
Club |
Alphanumérique |
60 |
|
Nom porté sur le certificat médical |
Alphanumérique |
30 |
|
Commentaire certificat médical |
Alphanumérique |
80 |
|
Date certificat médical |
Date |
8 |
|
Médecin traitant |
Alphabétique |
30 |
|
Date d’inscription |
Date |
8 |
|
Catégorie de l’inscription |
Alphanumérique |
20 |
|
Date compétition |
Date |
8 |
|
Libellé de la compétition |
Alphanumérique |
40 |
|
Ville de compétition |
Alphanumérique |
60 |
|
Distance de l’épreuve |
Numérique |
6 |
|
Descriptif de l’épreuve |
Alphanumérique |
60 |
|
Libellé du type de l’épreuve |
Alphanumérique |
80 |
Les champs Téléphone et Fax sont de type alphanumérique, car les utilisateurs peuvent saisir des caractères séparateurs.
Le code postal aussi est de type alphanumérique, car si en France nous utilisons cinq chiffres, il n’en est pas de même dans d’autres pays.
Retenez cette règle simple : seuls les champs sur lesquels des calculs seront réalisés doivent être déclarés en type numérique.
b. Le modèle conceptuel des données
À la lecture du dictionnaire des données, nous pouvons dégager les entités suivantes :
-
Sportif
-
Inscription
-
Compétition
-
Épreuve
-
Type de l’épreuve
Voici maintenant les entités remplies avec leurs propriétés.
Intéressons-nous aux relations. Un sportif enregistre son inscription à une compétition qui est composée d’épreuves d’un certain type.
La présence d’identifiants relatifs indique que si une épreuve est supprimée, la compétition et l’inscription doivent être aussi supprimées.
Si nous regardons attentivement ce modèle, nous pouvons aussi nous demander si nous ne pouvons pas spécialiser l’entité SPORTIF. En effet, un sportif peut être soit licencié, soit amateur.
Voici le modèle qui découle de cette remarque.
c. Le modèle logique des données
Le modèle logique qui en découle peut être le suivant :
Ce modèle a été généré par le logiciel WinDesign. Au niveau des entités LICENCIE et AMATEUR, vous avez plusieurs possibilités :
Soit, comme dans le schéma précédent, vous dupliquez la totalité de l’entité surtype dans les entités sous-types. Cette solution entraîne des redondances d’informations, mais l’intégralité des informations du sportif figure dans chaque table, ce qui peut être un gage de rapidité d’accès à toutes les informations du sportif.
Soit vous ne dupliquez que l’identifiant de l’entité surtype dans les entités sou-types. Cette solution est la plus élégante, de plus l’espace nécessaire aux données est optimisé.
Soit vous ne conservez que les entités sous-types après avoir dupliqué le contenu de l’entité surtype. Cette solution évite de gérer la table SPORTIF, donc évite les doublons de données.
Soit vous passez toutes les propriétés des entités sous-types dans l’entité surtype. Cette solution, la plus simpliste, produit une table ayant un grand nombre de champs vides.
