Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

Merise Analyser un Système d’Information déroute parfois le non-initié, car tra

Merise Analyser un Système d’Information déroute parfois le non-initié, car traduire un environnement de travail en symboles cabalistiques n’est pas très habituel pour qui ne connaît pas. Pourtant, avec une once de théorie et deux grammes de pratique, on se rend compte que le processus est très abordable, soumis à quelques règles simples, faciles à acquérir et qui s’appliquent toujours de la même manière. La méthode décrite ici est MERISE, elle est Française et a plus de 20 ans. Elle consiste à concevoir un Modèle Conceptuel de Donnée (MCD), le transposer en Modèle Logique de Données Relationnelles (MLDR), puis à générer le Modèle Physique correspondant (MPD). C’est la plus répandue des techniques d’analyse de Base de Donnée. Nous étudierons plus particulièrement aujourd'hui la construction du Modèle Conceptuel de Donnée et de ses 5 caractéristiques : Entités, Propriétés, Identifiants, Associations, Cardinalités. Le Système d'Information La priorité est de transformer ce que l’on veut analyser en mots simples. L’écriture de cette petite rédaction permet à elle seule de bien comprendre ce que l’on va modéliser. Il s’agit à ce stade d’établir un lien entre l’informaticien et les utilisateurs, il ne faut donc pas hésiter à faire relire votre petit texte et à poser toutes les questions qui vous viennent à l’esprit afin de bien analyser l’existant. La difficulté principale est d’arriver à faire abstraction de vos habitudes de programmation : à ce stade, nous sommes totalement indépendant du matériel et du logiciel. Ne pensez pas en termes de tables. Pensez en termes d’entités. Prenons l’exemple très simple d’un logiciel ayant pour but de gérer les envois de Newsletters aux abonnés d’un site ayant plusieurs rubriques. Le service marketing veut aussi savoir quelle raison a poussé l’abonné à s’inscrire en lui proposant plusieurs choix de motivations lors de son inscription. Le Système d’Information se décrit ainsi : "Un abonné est inscrit à une ou plusieurs rubrique. Chaque rubrique envoie une NewsLetter chaque semaine aux abonnés de la rubrique correspondant. Un abonné a une motivation d’inscription parmi plusieurs possibles." Ces quelques phrases, si elles sont exactes et validées par le client, sont suffisantes pour modéliser notre premier modèle. Elles contiennent en effet toutes les informations nécessaires. Identifier les entités présentes L’entité ABONNES représente l?ensemble des abonnés. L?entité RUBRIQUES l?ensemble des rubriques auquelles l?abonné peux s?inscrire. L?entité NEWSLETTERS représente les newsletters envoyées, MOTIVATIONS l?ensemble des motivations d?inscriptions des abonnés. D?où les 4 entités : Généralement, une entité est crée dans le Système d?Information si elle possède au moins 2 occurrences. Chaque ?élément d?une entité? est appelé une occurrence de l?entité. Lister les propriétés des entité Un Abonné est caractérisé par son nom, son prénom, son âge, son sexe, sa profession, sa rue, son code postal, sa ville, son pays, son téléphone et son email. Une Newsletter est caractérisée par son sujet, sa date d?envoi et son contenu. Une Motivation est caractérisée par son intitulé. Une Rubrique est caractérisée par son nom. Les 4 entités deviennent : Afin de ne pas en avoir trop, on se limite généralement aux propriétés nécessaires au développement. Chaque propriété doit avoir une seule valeur possible pour chaque occurrence, sinon il s?agit d?une entité. Elle doit de plus être élémentaire et non-décomposable. Par exemple, l?adresse n?est pas une propriété élémentaire : elle comporte une rue, un Code Postal et une ville qui elles, sont 3 propriétés élémentaires. Identifier de manière unique chaque occurrence Imaginons que nous ayons deux abonnés qui s?appellent ?DUPOND : il est nécessaire de les distinguer sous peine de les confondre. On rajoute alors une propriété qui permettra d?identifier de manière unique chaque occurrence. Cette propriété est appelé l?identifiant de l?entité. Cela peut être une référence interne, un code, ou plus généralement un nombre entier. Cette propriété est soulignée afin de mettre en évidence son rôle d?identifiant. Les 4 entités sont finalement : Etablir les relations entre les différentes entités Maintenant, il s?agit d?identifier les relations entre les entités. Généralement, la simple transposition du texte suffit, les Sujets et Compléments d'Objets étants les entités, et les Verbes les relations. Reprenons notre texte initial : "Un Abonné a une Motivation. Un Abonné s?inscrit à une ou plusieurs Rubriques. Chaque Rubrique envoie une NewsLetter." Les verbes sont en rouge et relient les entités. Il suffit de les intégrer au schéma : Identifier les cardinalités Il faut maintenant établir le nombre possible d?interactions entre les entités. Il s?agit d?un couple d?entiers de type ( a ; b) . a est la cardinalité minimum, et est égal à 0 ou 1. b est la cardinalité maximum, et est égal à 1 ou n, n étant plus grand que 1. Continuons notre exemple : Un Abonné a ici une et une seule Motivation d?inscription, le marketing ayant imposé un champ obligatoire afin d?avoir cette valeur. On a donc 1 minimum, et 1 maximum. D?où la cardinalité (1;1). Une Motivation donnée concerne 0 ou plusieurs Abonnés. On a donc 0 minimum, et n en maximum. D?où la cardinalité (0;n). De même, un Abonné s?inscrit à une ou plusieurs Rubriques : (1;n), Et une Rubrique possède 0 ou plusieurs Abonnés : (0;n). Enfin, une Rubrique envoie 0 ou plusieurs Newsletters : (0;n), Et une Newsletter appartient à une et une seule Newsletter : (1;1). Il suffit maintenant de marquer ces couples sur le schéma, et nous avons notre Modèle Conceptuel de Donnée (MCD) : Valider le Modèle avec le client A ce stade, il est aisé d?aller voir encore une fois les utilisateurs du logiciel final, afin de discuter le MCD avec eux. Cela vous permettra d?entériner les propriétés qu?ils désirent utiliser, d?être bien certain des cardinalités, et de valider avec eux cette partie de votre travail. Un MCD doit pouvoir s'expliquer avec des phrases simples et être compréhensible par tout le monde. Il ne s?agit ni plus ni moins que de modéliser l?existant. Ainsi, vous serez certain de faire le développement demandé, et cela vous permettra de vous protéger par la suite en cas de nouvelles demandes ou de modification du cahier des charges. Il est important de bien réaliser que jusqu'à ce stade, toute cette analyse s?est déroulée totalement indépendamment de la machine ou de toute contrainte logicielle. Ces règles fonctionnent toujours, même si il peut y avoir parfois plusieurs solutions pour chaque modèle. Le processus de modélisation, après quelques tentatives, est très simple à acquérir. Enfin, une fois le Modèle Conceptuel de Donnée établi, vous aurez fais le plus difficile. La conception de la base qui en découle est mécanique, et repose sur 6 règles strictes, nécessaires et suffisantes. Transformer un MCD en Modèle Logique, puis Physique est tellement standardisé que certains logiciels le font automatiquement.... Coin Technique Merise : 2ème partie Après avoir conçu le Modèle Conceptuel de Donnée (MCD), il est maintenant temps de le transposer en Modèle Logique de Données Relationnelles (MLDR). Ce MLDR est en fait le dernier pas vers le Modèle Physique de donnée(MPD), c'est à dire la description de la base qui va être crée. Et là, deux solutions s'ouvrent à vous : soit vous laissez à un programme le soin de transformer votre MCD, soit vous le faîtes vous-même. Dans les deux cas, il est utile d'avoir un minimum de connaissance théorique sur le sujet. Après avoir définis les notions de clé primaire et de clé étrangère, nous étudierons plus particulièrement aujourd'hui les 6 règles strictes, nécessaires et suffisantes pour passer d'un MCD à un MLDR, et nous les appliquerons ensuite au schéma de Newsletter que nous avons écris la dernière fois. Préliminaires : le Modèle Logique de Donnée (MLD) Il s'agit du passage entre le Modèle Conceptuel de Donnée et l'implémentation physique de la base. Le MLD est lui aussi indépendant du matériel et du logiciel, il ne fait que prendre en compte l'organisation des données. C'est d'ailleurs le point primordial de la modélisation : si l'organisation des données est relationnelle (si elles sont "liées" entre elles), alors le MLD est Relationnel et devient le MLDR, ou Modèle Logique de Donnée Relationnel. Pour la petite histoire, le MLDR a été inventé par Codd en 1970, et repose sur la Théorie Ensembliste... Un peu de vocabulaire : Les données sont stockées dans des relations. Une relation est un ensemble de T-uple, et un T-uple est définis par un ou plusieurs attributs. Dans la pratique, la relation est en fait la table, un T-uple est une ligne (ou enregistrement), et les attributs sont les colonnes. Exemple de la table NEWSLETTER : Cette table est décrite par : NEWSLETTER (id_newsletter, Sujet, DateEnvoie, Contenu, #id_rubrique) Chaque enregistrement doit être identifié de manière unique (voir la notion d'identifiant abordée dans l'article précédent). L'attribut qui permet d'identifier de façon unique chaque ligne est appelée la Clé Primaire. Elle peut être composée, c'est à dire comprendre plusieurs attributs. Ici, il s'agit de l'attribut id_newsletter. La table Newsletter comprend un attribut provenant de la table RUBRIQUES, l'attribut id_rubrique. Cet attribut est appelé Clé Etrangère. Dans le formalisme, la clé primaire est soulignée, et la clé étrangère est précédée du signe #. D'où uploads/Management/ cour-merise-1.pdf