Cours A.C.S.I. Analyse et Conception des Syst`emes d ..., Schémas de Informatique

Télécharge Cours A.C.S.I. Analyse et Conception des Syst`emes d ... et plus Schémas au format PDF de Informatique sur Docsity uniquement! Cours A.C.S.I. Analyse et Conception des Systèmes d’Information Semestre 1 IUT de Belfort Abdallah Makhoul et Karine Deschinkel Sources : Jacques Peltier et Bernard Morand 23 août 2019 Table des matières 1 Introduction à l’A.C.S.I 2 1.1 Que signifie A.C.S.I? . . . . . . . . . . . . . . . . . . . . . . . . 2 2 La conception d’un système d’information 4 2.1 L’entreprise : un système . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1 La structure du système entreprise . . . . . . . . . . . . . 4 2.2 Le système d’information et l’entreprise . . . . . . . . . . . . . . 5 2.2.1 Le Système d’Information (SI) . . . . . . . . . . . . . . . 5 2.2.2 Les trois cycles du SI . . . . . . . . . . . . . . . . . . . . 6 2.3 La méthode MERISE . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 La composition des niveaux du cycle d’abstraction . . . . 8 3 Le Modèle Conceptuel de Données (MCD) 10 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1 Exemple commande dans un magasin . . . . . . . . . . . 10 3.2 Concepts manipulés . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1 Entité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2 Association . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.3 Propriété . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.4 Notion d’occurrence . . . . . . . . . . . . . . . . . . . . 14 3.2.5 Notion d’identifiant . . . . . . . . . . . . . . . . . . . . . 17 3.2.6 Identifiant d’une association . . . . . . . . . . . . . . . . 19 3.3 Les cardinalités . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.4 Dimensions d’une association . . . . . . . . . . . . . . . . . . . 21 3.4.1 Dimension supérieure à 2 d’une association et cardinalités 23 3.4.2 Décomposition de certaines associations de dimension supérieure à 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.5 Construction du MCD . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5.1 Méthode pratique d’élaboration d’un MCD . . . . . . . . 39 3.5.2 Vérification du modèle . . . . . . . . . . . . . . . . . . . 40 1 Chapitre 2 La conception d’un système d’information 2.1 L’entreprise : un système L’entreprise répond à la définition d’un système, c’est à dire que c’est un en- semble d’éléments en interaction dynamique organisé en fonction d’un but. Dans le vocabulaire de l’analyse systémique, une entreprise est aussi nommée une organisation. 2.1.1 La structure du système entreprise Système de Pilotage Système d’Information Système Opérant L’entreprise est un système composé du système de pilotage, qui est en soi le système nerveux de l’entreprise : il prend les décisions, fixe les objectifs et les moyens de les atteindre, il dirige l’entreprise et maintient le cap sur les objectifs choisis. Le système de pilotage irrigue tous les niveaux de l’entreprise, depuis l’enca- drement jusqu’à l’exécution des tâches. Le système opérant est la partie de l’en- treprise qui exécute toutes les tâches. Il répond à la finalité de l’entreprise. Le système d’information sert à traiter l’information et à la véhiculer entre le système de pilotage et le système opérant. Il transmet au système opérant les instructions du système de pilotage. Il informe après analyse le système de pi- lotage des résultats du système opérant. Le système d’information est ouvert sur l’environnement extérieur avec lequel il échange des informations. 4 2.2 Le système d’information et l’entreprise 2.2.1 Le Système d’Information (SI) Le système d’information est composé d’éléments divers (employés, ordi- nateur...) chargés de stocker et de traiter les informations relatives au système opérant afin de les mettre à la disposition du système de pilotage. Il peut en outre recevoir de celui-ci des décisions destinées à son propre pilotage. Enfin il peut émettre vers le système opérant des informations-intéraction, c’est à dire qu’il peut réagir sur le système opérant. D’après Le Moigne, le SI est l’ensemble des méthodes et moyens recueillant, contrôlant, mémorisant et distribuant les informations nécessaires à l’exercice de l’activité de tous les points de l’organisation. Ainsi, le SI présente quatre fonc- tions : — collecter et contrôler les informations qui viennent soit de l’intérieur, soit de l’extérieur de l’organisation (les éléments de l’extérieur qui échangent avec l’organisation font partie de l’environnement) ; — mémoriser les données manipulées ; — traiter les données stockées ; — transmettre des informations vers les autres membres de l’organisation étudiée, ou vers l’environnement. FIGURE 2.1 – Le flux d’activité opérationnelle La figure 2.1 représente la transformation du flux entrant en flux sortant par le système opérant, ce qui s’appelle le flux d’activité opérationnelle. 5 2.2.2 Les trois cycles du SI Pour étudier un SI, on suit traditionnellement trois cycles : — le cycle de vie, — le cycle d’abstraction, — le cycle de décision. Le cycle de vie Il traduit le cheminement chronologique du SI depuis sa création et son développement, jusqu’à son obsolescence et sa remise en cause. FIGURE 2.2 – Les étapes d’un cycle de vie d’un SI La figure 2.2 présente les différents étapes du cycle de vie d’un SI : — La conception est le moment de fournir une description fonctionnelle et technique du SI. — La réalisation est le moment où l’on réalise les programmes avec les tech- niques retenues au moment de la conception. — La maintenance permet de prolonger la vie du système en l’adaptant aux besoins nouveaux de l’entreprise. — Le déclin est le moment où le SI devient obsolète (= dépassé). Un nouveau cycle de vie devra alors commencer. Le cycle d’abstraction Il traduit les différents degrés d’abstraction du SI au cours de sa vie. On dis- tingue trois niveaux pour le cycle d’abstraction d’un SI, qui correspondent à trois niveaux de préoccupation successifs dans la modélisation d’un SI : — le niveau conceptuel, — le niveau logique, — le niveau physique. Ces trois niveaux seront détaillés dans la prochaine section. Le cycle de décision Il traduit l’ensemble des mécanismes de décisions lors du développement du SI. Il est indispensable d’identifier les personnes aptes à prendre les décisions et 6 Niveau Règles Contenu Conceptuel Gestion données traitées, enchainement des traitements,... Logique Organisation partage homme/machine, distribution,... Physique Technique programmes, écrans, états, matériel, réseau 9 Chapitre 3 Le Modèle Conceptuel de Données (MCD) 3.1 Introduction Le modèle conceptuel des données (MCD) a pour but d’écrire de façon for- melle les données qui seront utilisées par le SI. Il s’agit donc d’une représentation des données, facilement compréhensible, indépendamment de tout choix d’im- plantation physique. Le MCD représente la version statique de SI. 3.1.1 Exemple commande dans un magasin On considère la liste d’informations suivante, donnée par ordre alphabétique : 1. Date de la commande 2. Désignation du produit 3. No de la commande 4. No du produit 5. Prix unitaire 6. Quantité commandée Intuitivement, les informations se rangent parmi les deux grandes catégories d’information suivantes : PRODUIT, COMMANDE. La répartition des infos par catégorie est la suivante : COMMANDE PRODUIT -Date commande -Quantité cdée -Désignation -No commande -No produit -Prix unitaire 10 Il est à noter que l’info ”quantité commandée”, dépend à la fois du produit et de la commande. On peut établir le lien smantique ”CONCERNER” entre ces deux groupes d’informations (ou catégorie, ou centre d’intérêt). Le schéma ci-dessous résume informellement l’analyse que l’on a faite de ces infos. FIGURE 3.1 – Concepts d’un MCD 3.2 Concepts manipulés 3.2.1 Entité Définition 6 (ENTITÉ) Une entité est un concept manipulé par l’entreprise, pourvu d’une existence propre, et conforme aux besoins de gestion de l’entreprise. Le critère d’EXISTENCE PROPRE peut paraı̂tre vague à première vue : com- ment peut-on décider que quelque chose existe? C’est en fait la fonction du modèle (un dessin pour le moment) que de dire ce que le concepteur qui observe le monde a retenu de ce monde. Autrement dit ce qu’il en estime pertinent : Les commandes pourraient être vues comme un simple lien sémantique (une association, donc) entre une entité CLIENT et une entité PRODUIT. C’est pourquoi : 1. pour une réalité ”donnée” le modèle dépend du concepteur 2. la fabrication d’un modèle ne peut être le travail d’un individu isolé : il faut que plusieurs personnes (concepteurs, utilisateurs, dveloppeurs, res- ponsables) s’accordent sur ce qui est pertinent. Remarque 7 Dans l’exemple précédent, on peut dire que PRODUIT et COM- MANDE existent par eux mêmes, et sont donc dotés d’une existence propre. Ce 11 2. Une entité possède au moins une propriété (son identifiant : par exemple le No de commande). 3. Il n’est pas possible qu’une entité porte plusieurs fois la même propriété. Par exemple, si un fournisseur a deux adresses, on doit dénommer de deux manières distinctes ces deux adresses (par exemple adresse du siège so- cial, adresse du magasin). Il arrive que le nombre de valeurs d’une pro- priété varie d’une instance (=un exemplaire) à l’autre d’une entité. Par exemple, tous les fournisseurs n’ont pas nécessairement le même nombre d’adresses. Certains ont un siège social dans leur magasin, d’autres peuvent avoir plusieurs magasins... Dans ce cas, on est amené à créer une entité spécifique l’adresse (reliée au fournisseur par une association). 4. Une association peut ne pas avoir de propriété. 5. Toute propriété portée par une association est nécessairement partagée par l’ensemble des entités reliées par cette association. 6. De la même manière qu’une entité ne peut pas porter plusieurs fois la même propriété, une association ne peut pas porter plusieurs fois la même propriété. 3.2.4 Notion d’occurrence Les concepts qui apparaissent sur le modèle sont là pour résumer et pour éviter l’énumération fastidieuse de tous les faits individuels du système d’information. Un exemple de description exhaustive pourrait être la suivante : FIGURE 3.2 – Occurences La commande no 1234 concerne un seul produit : 5 boı̂tes de ED12 au prix unitaire de 123.56. La commande no 1356 concerne 3 produits : AZ34, KB53 et ED12. Le produit AZ34 est demandé par une commande, le produit KB53 également. 14 Le produit UW79 n’est pas demandé. Cela ne paraı̂t pas être une anomalie. Le produit ED12 est demandé dans 2 commandes. La commande no 1246 ne concerne aucun produit, c’est du moins ce que dit le modèle. Il peut y avoir deux explications à cette anomalie surprenante : — soit l’anomalie est dans le monde : il est des commandes qui ne concernent pas des produits (une histoire de Pre Nol par exemple) — soit l’anomalie provient d’une non-conformité du modèle au monde. Pour éviter dans la mesure du possible cette dernière, on aura recours aux cardi- nalités (cf. section 3.3). La figure 3.2 représente ce qu’on appelle un schéma en épaisseur, qui énumère exhaustivement tous les individus et liens du domaine. D’où cette dfinition : Définition 10 (Occurence) L’occurence est une réalisation particulière d’une en- tité, propriété ou association. Synonyme : INSTANCE L’occurence d’une propriété est une valeur que peut prendre cette propriété. Par exemple, l’occurrence de la propriété Prix unitaire pour le produit ED12 est 123.56. Un autre exemple : les occurrences d’une propriété qui serait ”saison” sont prin- temps, été, automne, hiver. Une occurrence d’une entité est un ensemble ayant une existence propre d’occur- rences de ses propriétés, avec une occurrence par propriété. Une occurrence de l’entit COMMANDE c’est : no 1234 du 28/03/98. Un deuxième exemple, on considère une entité SALARIÉ ayant comme propriétés — Numéro salarié — Nom salarié — Prénom salarié — Date de naissance Une occurrence de SALARIÉ est par exemple — S14358 — MARTIN — Pierre — 20.10.1978 Remarques 11 — Il est important de s’assurer que toutes les propriétés de l’entité ont un sens quelque soit l’occurrence de l’entité. Si ce n’est pas le cas, il est conceptuellement nécessaire de créer une autre entité. 15 — Certaines occurrences de propriété peuvent être répétées sur des occur- rences d’entité distinctes. Cela est sans importance s’il existe au moins une propriété pour laquelle cela ne se produit jamais. — Aucune propriété ne doit prendre plus d’une valeur pour une occurrence donnée de l’entité (exemple : numéro de téléphone fixe et portable). Il faut donc s’assurer qu’une entité ne comporte pas de propriétés répétitives. Si cela se présente, il faut soit créer sur l’entité autant de propriétés différentes qu’il y’a de possibilités de répétition, soit créer une autre entité portant cette propriété et l’inclure dans une association avec l’entité de départ. Cette seconde solution est le plus souvent préférable car elle ne limite pas le nombre d’occurrences possibles de la propriété. Une occurrence d’une association est définie par rapport aux occurrences de ses constituants. Une occurrence d’une association est constituée d’une et une seule occur- rence de chacune des entités associées, et d’une occurrence de chacune des pro- priétés qu’elle porte, correspondant aux occurrences des propriétés associées. Par exemple : l’occurrence de l’association CONCERNER : 5 produits ED12 pour la commande no 1234. Chacune des propriétés de l’association ne peut avoir qu’une seule occurrence (valeur) pour chacune des occurrences de l’association. Chaque propriété de l’as- sociation doit avoir une occurrence (valeur) pour chaque occurrence de l’associa- tion. Exemple : Une occurrence de ”réserve” c’est : — une occurrence de VACANCIER; — une occurrence de HOTEL; — une date d’arrivée du vacancier l’hôtel ; — une date de départ du vacancier de l’hôtel. 16 3.2.6 Identifiant d’une association Une association N’A PAS D’IDENTIFIANT explicite : l’association dépend des entités qu’elle relie. Son identifiant se déduit par calcul du produit cartésien des identifiants des entités associées. Exemple : Pour l’association CONCERNE qui relie COMMANDE à PRO- DUIT, l’identifiant est le produit cartésien de No Commande et No Produit. 3.3 Les cardinalités La cardinalité est une notion OBLIGATOIRE du modèle qui permet de résoudre la question de l’anomalie de la commande 1246 qui aurait pris la liberté de ne point comporter de produits. (La commande no 1246 ne concerne aucun produit, c’est du moins ce que dit le modèle ! !) C’est donc l’expression d’une CONTRAINTE (une ”loi”) perçue sur le monde, et que l’on écrit dans le modèle. Par exemple, ”il n’est pas possible qu’une com- mande ne concerne aucun produit”. POUR UNE OCCURRENCE DE CETTE ENTITÉ, combien y a t’il d’occur- rences de l’association auxquelles cette occurrence d’entité participe, au plus et au moins? Pour calculer la cardinalité, se POSITIONNER sur l’entité concernée et regar- der EN FACE combien de fois l’une de ses occurrences participe à l’association. Puis se DEPLACER du côté de l’autre entité et faire la même chose dans l’autre sens. Considérons l’exemple de la figure 3.1, une commande concerne un produit : On doit indiquer, pour chaque entité vis à vis de chaque association qui s’y rat- tache, une cardinalité minimum, et une cardinalité maximum. Une cardinalité mi- nimum est soit 0, soit 1. Une cardinalité maximum est soit 1, soit n. Les deux entités sont représentées par deux classeurs contenant plusieurs fiches chacun. Une fiche représente une occurence de l’entité d’où la figure suivante : FIGURE 3.5 – Représentation classeurs-fiches 19 En observant les fiches du classeur Commande, c’est à dire les occurrences de l’entité COMMANDE, on remarque : — toute occurrence de COMMANDE est reliée à au moins (min : 1) une occurrence de PRODUIT, et éventuellement à plusieurs (max : n). Donc les cardinalités min et max de COMMANDE vis à vis de concerne est (1,n). — la fiche p5 n’a aucun lien avec le classeur COMMANDE. Autrement dit, il est possible à une occurrence de PRODUIT de n’être reliée à aucune occurrence de COMMANDE (cardinalité minimum de 0) ; — il est possible à une occurrence de PRODUIT d’être reliée à plusieurs oc- currences de COMMANDE (cardinalité maximum de n). Donc les cardi- nalités min et max de COMMANDE vis à vis de concerne est (0,n). Le modèle sera représenté comme suit : FIGURE 3.6 – Modèle avec les cardinalités Résumé CARDINALITÉS MINIMUM : Valeur Définition Exemple 0 Une occurrence de l’entité peut exister sans participer à l’asso- ciation un produit peut ne pas être com- mandé 1 Une occurrence de l’entité par- ticipe nécessairement au moins une fois à une occurrence d’as- sociation toute commande concerne au moins un produit CARDINALITÉS MAXIMUM : 20 Valeur Définition Exemple 1 Une occurrence de l’entité parti- cipe au plus une fois un employé travaille au plus dans un service N Une occurrence de l’entité peut participer plusieurs fois une commande peut concerner plusieurs produits CONFIGURATIONS POSSIBLES : Valeur Définition 0,1 Une occurrence participe au moins 0 fois et au plus 1 fois à l’assocciation 1,1 Une occurrence participe exactement 1 et 1 seule fois à l’assocciation 0,N Une occurrence peut ne pas participer ou participer plusieurs fois 1,N Une occurrence participe au moins 1 fois, voire plusieurs 3.4 Dimensions d’une association Définition 14 (Dimension d’une association) On appelle DIMENSION d’une as- sociation le nombre d’entités qu’elle relie. On dit souvent : son nombre de ”pattes”. Définition 15 (Collection d’une association) C’est l’ensemble des entités qui par- ticipent à l’association (i.e. qui sont reliées par l’association). La collection d’une association est composée au minimum d’une entité. En théorie, la dimension d’une association n’est pas limitée. Cependant un nombre de pattes élevé est un indice que l’étude a été superficielle et approximative. Il existe en effet un procédé de simplification que nous verrons plus loin. Les associations les plus fréquemment rencontrées en pratique sont de dimension 1, 2 ou 3. — Lorsque la dimension est 1, on parle d’association réflexive. — Lorsque la dimension est 2, on parle d’association binaire. — Lorsque la dimension est 3, on parle d’association ternaire. — Lorsque la dimension est supérieure à 3, on parle d’association n-aire. Cas particulier de l’association dite ”réflexive” : Supposons que pour l’arbre de Noël du Comité d’Entreprise nous ayons besoin de savoir quels sont, parmi nos employés, ceux qui sont mariés entre eux (ne pas donner 2 fois le cadeau à leurs enfants) voir la figure suivante : Une association ”réflexive” est une association qui lie des occurrences d’une même entité entre elles (c’est un cas particulier de la dimension 2). Si l’on repr- sente le schéma en épaisseur avec un seul exemple, on obtient en effet (avec en prime quelques problèmes supplémentaires) : 21 fait peut ne pas avoir eu lieu. En clair il existerait des clients pour lesquels rien n’est signé. Comme on le voit c’est un peu différent du cas précédent. Nous conseillons de ne retenir pour les associations que la 2ème interprétation : celle d’une trace d’événement et non celle d’un état de choses. En effet, si l’on veut représenter la condition de locataire d’un client (son état) il sera plus judi- cieux d’en faire un objet : l’association LOUER deviendra une entité LOCATION par exemple et identifiée en tant que telle. Remarque 16 Il y a là une remarque d’ordre très général : nous transformons les événements (associations) en entités lorsque nous voulons nous y référer très souvent et plus facilement. C’est un principe d’économie de mémoire auquel est lié le principe de nommage au moyen de mots. Commentaire : — Pour une occurrence de client, il y a au moins un couple local × contrat et au plus plusieurs (a) — Pour un local il peut ne pas y avoir de couple client× contrat mais éventuellement plusieurs (b) — Pour un contrat il y a 1 et 1 seul couple client × local (c) Remarques 17 (a) Observer que la cardinalité se calcule par rapport au ”couple” d’entités associées et non par rapport à une seule d’entre elles prise au hasard. Par exemple, on peut imaginer qu’un client ne puisse louer dans la galerie com- merciale qu’un seul emplacement (les gérants veulent éviter des situations mono- polistiques) : on aura tendance à mettre 1,1 sur CLIENT et ce sera pourtant faux si un client peut avoir plusieurs contrats pour cet emplacement (successifs par exemple, voir b) Ceci résulte de la définition de la cardinalité : pour une occur- rence de l’entité, combien d’occurrences de l’association? Et non pas : combien d’occurrences d’une entité ? Ce qui ne marche que dans le cas particulier d’une association de dimension 2 du fait de la pure coı̈ncidence entre l’association et l’entité qu’elle rattache. 24 (b) Comment un local peut-il faire l’objet de plusieurs locations? Ceci semble aller contre le bon sens : à un moment donné on ne peut avoir plusieurs lo- cations pour le même local. Tout dépend de ce que l’on entend par location : s’agit-il seulement des contrats actuellement en cours ou plus largement de tous les contrats y compris ceux qui sont révolus? Nous avons retenu la dernière hy- pothèse. C’est ce qu’on appelle ”gérer un historique” : nous voulons savoir par exemple qui était locataire il y a 20 ans. Observer que dans ce cas le modèle de- vient problématique : 2 locations successives du même local par le même client ne se distinguent plus que par le numéro de contrat. On aura intérêt à créer une entité LOCATION. ”A un moment donné” est une restriction qui ne fait pas partie de la définition de la cardinalité. (c) Le modèle, comme on pourrait le voir, n’est pas optimisé. Dans le cas d’une association de dimension supérieure à 2 et si l’on trouve une cardinalité 1,1 sur l’une des pattes, le modèle peut être décomposé. Pour l’instant, on peut le conser- ver tel qu’il est. En effet, l’association LOUER est indirectement identifiée par No Client × No Emplacement × No Contrat. Or dans cet identifiant complexe, la partie (No Client × No Emplacement) est une redondance puisqu’elle est en dépendance fonctionnelle du No Contrat. Pour identifier une occurrence de LOUER parmi toutes les autres, No Contrat suffit (le client et l’emplacement en sont déductibles). En fait, on peut considérer que l’entité CONTRAT est une excroissance de l’association LOUER et peut donc s’y substituer. On préférera donc la solution suivante : Supposons qu’il soit nécessaire de ” matriser les dépenses de santé”. Il nous faut savoir ce que font exactement les médecins du Centre Médical. Remplacer les points d’interrogation par des cardinalités : C’est plus facile que dans le 1er cas : Commentaire : — Pour une occurrence de médecin, il peut ne pas y avoir de couple patient × acte (le Directeur du centre par exemple qui ne participe pas aux consulta- tions) mais en général il y en a plusieurs. 25 — Pour un acte il peut ne pas y avoir de couple médecin × patient (un acte chirurgical qui n’est pas pratiqué dans notre centre par exemple) mais éventuellement plusieurs — Pour un patient il y a au moins un couple médecin * acte et éventuellement plusieurs Leçon : Comme le montre la discussion sur ces 2 petits exemples, la détermination des cardinalités n’est pas une décoration visant à agrémenter le dessin. Ce calcul nous contraint à réfléchir sur ce que nous sommes en train de dire dans le dessin, souvent à interroger le monde pour tenter de savoir ce qui s’y passe vraiment (par exemple quel est le rôle joué par le Directeur du centre dans le cas ci-dessus). Dans la détermination des cardinalités, c’est moins le résultat qui compte, que le raisonnement qui est conduit et : — qui permet d’interroger le monde — qui fournit le moteur nécessaire à la découverte de nouvelles entités et associations 3.4.2 Décomposition de certaines associations de dimension supérieure à 2 Il est très difficile de trouver des exemples d’association de dimension 4 et supérieure. Tous les ouvrages qui veulent en montrer une n’ont qu’un exemple : 26 Supposons maintenant qu’il existe une règle selon laquelle les théatres ont l’exclusivité des pièces représentées. Autrement dit, une pièce est jouée dans un théatre et un seul. Nous sommes en présence d’une CIF : la connaissance de la pièce implique celle du théatre (le seul qui soit autorisé à la mettre à l’affiche) On pourrait dessiner cette règle comme ceci : Mais, puisque connaissant la pièce, on peut en déduire le théatre, on peut détacher l’entité THEATRE de l’association JOUER : Si on sait dans quelles pièces jouent les acteurs, on pourra toujours retrouver le théatre associé chaque pièce. Plus généralement : Dans le cas d’une association de dimension supérieure à 2 et lorsqu’il y a une CIF, l’entité déterminée peut être détachée de l’association initiale pour rester associée avec la seule entité déterminante. Ce qui donne dans notre exemple la simplification suivante : Il peut paraı̂tre étrange que le modèle décomposé soit considéré comme plus simple alors qu’il comporte 2 associations au lieu d’une. Pourtant l’association de dimension 3 représente effectivement un cas de fi- gure beaucoup plus GENERAL que la version décomposée. En effet, elle autorise la même pièce à être jouée dans plusieurs théatres différents et même par des ac- teurs différents. On peut aussi se demander si on n’a pas intérêt á rester le plus général pos- sible, en vertu du principe qui dit que ”Qui peut le plus peut le moins” et pour 29 rester ”conceptuel”. C’est là une vraie question que vous devrez vous poser souvent en faisant vos modèles : — Plus on reste général, plus on autorise une diversité de situations du monde mais plus on reste VAGUE. — Plus on précise, plus on rend le modèle dépendant d’une situation perçue à un moment donné et donc moins ce modèle est susceptible d’encaisser des CHANGEMENTS dans le monde. La généralité est l’ennemie de la précision et réciproquement. Par ailleurs, plus un modèle est général, plus il permet de choses et plus il coûte cher : par exemple, on ne sait pas implémenter aisément une association de dimension 3 telle quelle dans une Base de Données (on doit faire une sorte de détour). C’est encore la raison pour laquelle certains modèles de données les interdisent en n’acceptant que des relations binaires (au sens ensembliste). CONCEVOIR, c’est donc aussi une sorte de problème d’optimisation sous contraintes. Il est convenu que l’on appliquera toujours la règle de décomposition du fait des CIF. On observera encore que, ce faisant, on peut s’être créé un nouveau problème. En décomposant nous avons perdu une information. Dans une association de dimension 3, une régle nous dit que : ”s’il existe une occurrence d’association, alors, il existe nécessairement une occurrence de cha- cune des entités associées”. Traduisons dans notre contexte : Si quelque chose est joué, il y a nécessairement un acteur, une pièce et un théatre. Or, cette information n’est plus donnée par le modèle décomposé. Il permet pour une occurrence d’acteur de jouer dans une pièce qui n’est à l’affiche d’aucun théatre. Si l’on veut éviter ce genre d’imprécision (on pourra toujours me dire que c’est ma faute : je n’avais qu’à ne pas utiliser des cardinalités mini à 0), on devra ajouter une association supplémentaire entre ACTEUR et THEATRE : (vous retrouverez ce problème sous le nom de ”jointure avec perte” dans les BD relationnelles). LE CAS EMBETANT OU LA DECOMPOSITION NE MARCHE PAS : DEUX ENTITES DETERMINENT A ELLES 2 UNE AUTRE ENTITE. Dans un lycée, les professeurs donnent des cours à des classes dans certaines matières. 30 Mais on sait encore que dans une matière, une classe n’a qu’un seul profes- seur. Ceci peut s’écrire ainsi : CLASSE * MATIERE → PROFESSEUR On peut se demander quelles conséquences cette notation surajoutée pourra bien avoir. A chaque fois que l’on surajoute une contrainte dans un modèle alors que son formalisme ne le prévoit pas en standard, la punition est que l’on devra ne pas oublier de coder cette règle au moment de l’implémentation : elle reste à la charge du programmeur. Ici, ce seront les procédures de saisie et mise à jour des classes, matières et profs qui devront s’assurer que pour chaque couple matière * classe il n’y a bien qu’un prof. Ce que le schéma de la BD sera bien incapable de vous garantir à lui tout seul. On réfléchira cependant à ce que pourrait apporter une entité COURS dans la résolution de la question. 31 — etc : même chose pour COMMANDE et ENTREPOT puis HYPERMARCHE et ARTICLE. Non simplifiables. — Par contre : HYPERMARCHE et COMMANDE : Une commande émane d’un seul hypermarché. Autrement dit la connaissance de la commande détermine un hypermarché-client unique. On doit simplifier ainsi : HYPERMARCHE peut être détaché de l’association CONCERNE (on dit que l’on ”coupe la patte”) pour rester en relation seulement avec COM- MANDE. Ce qui donne en définitive : FIGURE 3.9 – Le modèle provisoirement définitif et précis de la Centrale d’Achats Si l’on ne procède pas de cette manière (par simplification du général) et que l’on tente d’emblée de faire un modèle précis, on risque d’obtenir un résultat du type ci-dessous qui est INCORRECT : En effet, il montre les articles commandés d’une part, les articles stockés de l’autre mais il ne pourra jamais nous dire à quels entrepôts s’adressent les com- 34 FIGURE 3.10 – Un modèle incorrect de la Centrale d’Achats mandes. La raison en est que ce modèle est TROP DECOMPOSE (il a perdu ce qu’il y a de général dans le monde de la Centrale d’Achats) 35 Version 2 : Un entrepôt dessert une zone géographique : tous les hyper- marchés situés dans cette zone ne peuvent commander qu’à l’entrepôt le plus proche. Nous avons déjà vu que si l’on connaı̂t la commande, l’hypermarché est déterminé. Maintenant, si l’on connaı̂t l’hypermarché, l’entrepôt est déterminé. Donc, par transitivité, si l’on connaı̂t la commande, l’entrepôt est déterminé D’où la CIF suivante et le détachement qui en résulte : Et on obtient en dfinitive : FIGURE 3.11 – Centrale d’Achats à entrepôts géographiquement répartis 36 3.5 Construction du MCD 3.5.1 Méthode pratique d’élaboration d’un MCD 1. Analyser l’existant pour recenser l’ensemble des informations manipulées. Ce recensement s’effectue en examinant l’ensemble des supports existants, informatisés ou non (structure de fichiers, documents écrits (écran ou pa- pier), support d’acquisition de données (écran ou papier), en interviewant les différents utilisateurs du Système d’Information. Les règles de gestion, et en particulier celles de calcul, permettent aussi de compléter ce recen- sement. 2. Pour chaque information recensée, il faut maintenant en dégager la signifi- cation, et repérer les synonymes et les polysèmes (= un même terme ayant plusieurs sens). Il faut donc épurer le vocabulaire de façon à conserver des termes non ambigus partagés avec les utilisateurs. 3. Classer les informations recensées en grandes catégories d’information. Laisser de côté celles qui dépendent à la fois de plusieurs catégories d’in- formation. 4. Recenser l’ensemble des liens sémantiques entre les catégories d’informa- tion, et leur associer les informations laissées de côté à l’étape précédente. 5. Transformer chaque catégorie d’information en entité, et chaque lien sémantique en association, avec ses éventuelles propriétés. 6. Doter chaque entité d’un identifiant. 7. Normaliser en se posant pour chaque propriété du modèle les trois ques- tions suivantes : a) la propriété a-t-elle toujours une valeur (pour chaque occurrence de l’entité ou de l’association)? b) si oui, cette valeur est-elle unique? c) faut-il codifier l’information? (On codifie une information si elle a une liste finie de valeurs, liste par rapport à laquelle on veut contrôler la saisie). Si les réponses à ces 3 questions sont respectivement OUI - OUI - NON, alors la propriété est une propriété de l’entité/l’asscoiation traitée. Dans le cas contraire, il faut créer une nouvelle entité. 8. Évaluer l’ensemble des cardinalités. 9. Repérer les CIF en vue de simplifier le modèle. Exemple. Normalisation des propriétés d’une entité (étape 7). On considère l’entité SALARIÉ suivante : 39 Les réponses successives aux trois questions pour chacune des propriétés (autres que l’identifiant) donne : — nom salarié - Oui, Oui, Non — date naissance - Oui, Oui, Non — sexe salarié - Oui, Oui, Oui — situation de famille - Oui, Oui, Oui — diplômes - Non, Non, Oui Le MCD correspondant à cette entité normalisée est le suivant : 3.5.2 Vérification du modèle Après élaboration, le modèle doit être vérifié afin de corriger d’éventuelles erreurs. On sera particulièrment vigilants sur 4 points : — absence de propriétés répétitives ou sans signification ; — existence d’un identifiant pour toutes les propriétés ; — dépendance pleine des propriétés des associations (voir l’exemple ci-dessous) ; — cardinalités en conformité avec les règles de gestion mises en évidence. Exemple. Non dépendance pleine d’une propriété d’une association. La date de naissance ne peut pas être à la fois une propriété de PAYS et de INDIVIDU. 40