cours M P1 2 an

Conception et Modélisation des Systèmes d’Information MERISE : 

Conception et Modélisation des Systèmes d’Information MERISE

Slide 2: 

2 Ce cours a pour but d’introduire une méthodologie de conception du système d’information en s’appuyant sur la méthode MERISE.

Bases de données et méthode MERISE : 

3 Conception d’un système d’information (bases de données). Introduction aux bases de données relationnelles. Mise en œuvre d’une base de données (sous MS-Access). Bases de données et méthode MERISE

Introduction : 

Introduction

Conception de système d’information : 

5 Exemple Mise en place d’un système d’information pour gérer toutes les données nécessaires au bon fonctionnement d’une entreprise. Conception de système d’information

Problèmes dans le système actuel : 

6 Problèmes dans le système actuel Livraison à mauvaise adresse. Courrier en copies multiples. Obligation de rappeler à chaque communication téléphonique le nom, le prénom, l’adresse, etc.

Remarques : 

7 Remarques Les mêmes données se présentent avec des libellés différents (synonymes). Les mêmes données sont reproduites plusieurs fois dans des services différents (redondance). Une même donnée prend parfois des valeurs différentes. Exemple : adresse facturation dans le service commercial et dans le service comptable. Un service n’a pas toujours l’ensemble des données. Besoin de mémoriser et de traiter des données de quantité importante.

Suggestion : 

8 Suggestion Créer une fiche unique par client qui rassemble toutes les données accessibles par tous les services. Gérer toutes les fiches client sur un micro-ordinateur (en utilisant Access, Oracle…).

Questions : 

9 Questions Quelles sont les données à mémoriser? Comment minimiser les données redondantes? Comment structurer les données et conserver des liens entre données? Comment décrire les traitements sur les données? consultation, mise à jour.

Eléments de réponse : 

10 Eléments de réponse Utilisation d’un Système de Gestion de Bases de Données Relationnelles (SGBD-R) exemple : Access. Méthode de conception d’une Base de Données, exemple : Méthode MERISE.

Système d’information et MERISE : 

Système d’information et MERISE

I. Notion de Système d’Information I. 1. Notion de système pour l’entreprise : 

12 I. Notion de Système d’Information I. 1. Notion de système pour l’entreprise Un système est un ensemble d’éléments matériels ou immatériels (hommes, machines, méthodes, recettes, règles, etc.) unis par des relations qui transforme, par un processus, des éléments (les entrées) en d’autres éléments (les sorties).

Slide 13: 

13 Exemple : Une usine de montage de voitures. Modèle d’un atelier de fabrication :

Slide 14: 

14 Le système correspondant à l’activité de l’entreprise (transformation de flux) est appelé système opérant (SO). L’entreprise a aussi besoin d’un système de prise de décision lui permettant de réaliser les objectifs fixés. Ce système est appelé système de pilotage (SP).

Slide 15: 

15 Le SP procède à la régulation et au contrôle du système opérant en décidant du comportement de celui-ci.

Slide 16: 

16 Avec l’augmentation en quantité et en complexité des informations échangées entre ces deux systèmes, on a besoin d’avoir un autre système qui stocke et traite de façon plus efficace ces informations. Ce système est appelé système d’information (SI).

Slide 17: 

17 Modèle d’une organisation (ou entreprise) selon la théorie des systèmes : Système de Pilotage Système Opérant Entrée Sortie Système d’Information

I.2. Notion de Système d’Information (SI) : 

18 I.2. Notion de Système d’Information (SI) Le SI est composé d’éléments divers (employés, ordinateurs, règles et méthodes, etc.) chargés de stocker et de traiter les informations relatives au système opérant (SO) afin de les mettre à la disposition du système de pilotage (SP).

Slide 19: 

19 Le SI possède deux aspects : Aspect statique (ou aspect données) : base d’information, modèle (ou structure) de données. Aspect dynamique (ou aspect traitement) : circulation de l’information entre les différents acteurs, évolution chronologique et causale des opérations provoquées par des évènements.

Slide 20: 

20 Exemple d’un modèle selon systémique d’une entreprise qui assemble et commercialise des PC :

I.3. Système Automatisé d’Information (SAI) : 

21 I.3. Système Automatisé d’Information (SAI) Dans un SI, on retrouve des décisions (homme) des actions programmées (machine) partie automatisable du SI. Un SAI est un sous-système d’un SI dans lequel toutes les transformations significatives d’information sont effectuées par des ordinateurs. Un SAI permet une conservation et un traitement automatique des informations.

Slide 22: 

22 Un SAI doit être intégré : une même information n’est saisie qu’une fois en un point du système et est récupérée dans tous les fichiers concernés. durable et adaptable : les logiciels de traitement des données (programmes) sont indépendant des données.

II. Conception d’un système d’information : 

23 II. Conception d’un système d’information La conception d’un SI consiste en une modélisation de l’entreprise (pour une vision globale : modèle systémique), une modélisation de ses aspects statiques (données : entités et association inter-entités); une modélisation de ses aspects dynamiques (traitements : opérations déclenchées par des événements). Cette conception nécessite une approche progressive (niveaux d’abstraction).

II.1. Nivaux d’abstraction : 

24 Un SI doit être durable et adaptable aux changements. Par exemple, un changement de machine ne doit pas entraîner une modification majeure du système. Il est donc nécessaire de dégager des niveaux correspondant aux préoccupations différentes. II.1. Nivaux d’abstraction

a. Niveau conceptuel : 

25 a. Niveau conceptuel A ce niveau, sont représentées les informations et leurs relations, les utilisations qui en sont faites et les contraintes associées. Ce niveau définit les finalités de l’entreprise, c.-à-d. la réponse à la question « que fait le système? » C’est le niveau le plus stable, il est invariant.  Modèle Conceptuel de Traitement Recueillir, organiser et structurer l’information Créer l’architecture  Modèle Conceptuel de Donnée

b. Niveau organisationnel (ou logique) : 

26 b. Niveau organisationnel (ou logique) Ce niveau est moins stable. Il définit l’organisation à mettre en place dans l’entreprise : il répond aux questions «comment?», « qui fera quoi, où et quand? »  Modèle Logique de Donnée  Modèle Organisationnel de Traitement Envisager les solutions organisationnelles et logiques possibles face aux contraintes posées

c. Niveau opérationnel (technique ou physique) : 

27 c. Niveau opérationnel (technique ou physique) Ce niveau est le moins stable. Il est souvent mis en cause par le changement du matériel et/ou des logiciels. Il définit l’ensemble des moyens techniques, composé de machines, de programmes et de fichiers, pour répondre aux objectifs posés.  Modèle Physique de Donnée  Modèle Physique de Traitement Faire le choix du matériel et des logiciels compatibles avec les solutions proposées.

Slide 28: 

28

Slide 29: 

29 Différencier données et traitements entité = objet, individu du système association = lien, relation entre ces entités etc … opération déclenchée par un évènement fait survenant Donnée : Traitement : Evènement :

II.2. Flux d’information : 

30 II.2. Flux d’information Une entreprise a besoin d’échanger des informations entre d’une part, les composants du SI et d’autre part, entre le SI et l’univers externe. Ces informations sont portées par des événements. Définition : on parle d’un événement lorsque quelque chose survient et lorsqu’on s’en aperçoit. Un événement déclenche une opération. Exemple : passation de commande → édition d’un bon de commande, arrivée du bon de commande au service commercial → consultation du stock, etc.

II.3. Traitements : 

31 II.3. Traitements Les traitements sont des opérations du SI déclenchées par l’arrivée d’événements. Exemple : l’arrivée d’une commande d’un client déclenchera la mémorisation de celle-ci et la recherche des produits commandés. Exemple : l’arrivée de l’événement « Déclaration de sinistre » déclenche l’opération « Vérifier la garantie ». Un traitement peut être manuel ou automatique dans un SI. Une BD ne s’intéresse qu’à la partie automatisable du SI.

II.4. Données : 

32 Entité (objet ou individu). Représentation dans un SI d’un objet de l’entreprise. Exemple : client, commande, produit, etc. Association (ou relation). Lien entre les entités. Exemple : client passe une commande. Attribut (propriété ou donnée). Rubrique de description d’une entité ou d’une association. Exemple : nom et adresse du client (attribut de l’entité «client»); date de la commande (attribut de l’association passation de commande»). II.4. Données

Modèle conceptuel de données (MCD) : 

Modèle conceptuel de données (MCD)

Slide 34: 

34 L’objectif de MCD est de proposer une représentation schématique de la partie statique de l’entreprise (données et liens) en utilisant le formalisme d’entité/association qui soit abordable par tout utilisateur permettant un dialogue clair avec les concepteurs. Le MCD obtenu ne doit inclure que des données nécessaires au fonctionnement de l’entreprise et les liens existants entre ces données.

I. Approche intuitive : exemple. : 

35 I. Approche intuitive : exemple. Soit la liste des données recensées dans un établissement scolaire : adresse de l’élève, matière enseignée, nombre d’heures, nom de la classe, nom du professeur, nom de l’élève, prénom de l’élève, note, numéro de salle. Soient les règles de gestion : R1 : à chaque classe est attribuée une et une seule salle. R2 : chaque matière est enseignée par un et un seul professeur. R3 : pour chaque classe et chaque matière est défini un nombre fixe d’heures de cours. R4 : à chaque élève est attribuée (au plus) une seule note par matière. R5 : l’établissement gère les emplois du temps des professeurs et des élèves ainsi que le contrôle des connaissances.

Slide 36: 

36 Regroupement des données : données liées à la classe : nom de la classe, numéro de la salle. données liées à l’élève : nom de l’élève prénom de l’élève adresse de l’élève données liées à la matière : matière enseignée nom du professeur.

Slide 37: 

37 Trois objets indépendants : classe, élève et matière. Les données comme «note», «nombre d’heures» seules n’ont pas de signification en tant que telles : la note dépend à la fois de l’élève et de la matière. le nombre d’heures dépend à la fois de la classe et de la matière. Les données qui dépendent de plus que d’un objet décrivent des liens entre ces objets : ex. «élève» «avoir pour note dans» «matière».

II. Concepts de baseI.1. Définitions (entité, association et attribut) : 

38 Entité : représentation concrète ou abstraite d’un objet appartenant au réel perçu à propos de laquelle on veut enregistrer des informations. Exemple : l’objet «élève». Association : représente un lien entre deux ou plusieurs entités (non nécessairement distinctes). Exemple : l’association «avoir pour note dans». Attribut (propriété) : caractéristique ou qualité qui décrit une entité ou une association. Exemple : l’attribut «prénom de l’élève» de l’entité «élève». II. Concepts de baseI.1. Définitions (entité, association et attribut)

Slide 39: 

39 Type d’un attribut : alphabétique (A), alpha-numérique (AN) ou numérique (N). Format : Entier, réel (xxxxx,xx), date (jj/mm/aa). Dimension d’un attribut : nombre de caractères nécessaires pour le coder. Exemple : Dim(Nom)=10, Dim(CAm)=9. Nature d’un attribut : un attribut peut être soit élémentaire (E) soit concaténé (CON) (s’il est du type AN par exemple). soit élémentaire (E) soit calculé (CAL) (s’il est du type N).

Slide 40: 

40 Attribut composé ( attribut concaténé) exemple : Adresse = {N°}+ {Rue}+ {Code postal}+ {ville}. Attribut dérivé ( attribut calculé) exemple : L’âge à partir de la date de naissance. Valeur d’un attribut : symbole utilisé pour représenter un fait élémentaire. Domaine : ensemble des valeurs que peut prendre un attribut. Exemples : Couleur  {rouge, orange, jaune, vert, bleu, violet} Age  {x: x>0 et x<120}. Prix des produits de 10 à 10000 DH.

Slide 41: 

41 Dictionnaire des données : liste des attributs nécessaires pour la gestion visée, avec précision sur leur type, nature, dimension, format ainsi que sur leur signification.

Exercices:Établir le dictionnaire de données coresponadants aux textes ci dessous : 

42 Exercices:Établir le dictionnaire de données coresponadants aux textes ci dessous Texte-1- Texte-2-

Slide 43: 

43 II.2 Occurrences Occurrences d’une entité : l’entité exprime un type, un ensemble dont les éléments sont appelés occurrences de l’entité. Exemple : l’entité « élève » aura quatre occurrences : Abdeilah Alarbi Safae Chafiq Najah Occurrences d’un attribut : Les propriétés (attributs) prennent des valeurs appelées également occurrences de la propriété. Exemple : l’attribut « prénom de l’élève » prend l’une des valeurs : {Safae, yassir, , }

Slide 44: 

44 L’entité et ses propriétés sont schématisés graphiquement comme suit Dans l’exemple traité :

Slide 45: 

45 II.3. Identifiant d’une entité : Une entité doit être dotée d’un identifiant. L’identifiant fait partie des propriétés de l’entité. Sa valeur doit être différente pour chaque occurrence de l’entité : il décrit chaque occurrence de l’entité d’une façon unique.

Slide 46: 

46 Pour distinguer les Alaoui, on ajoute un attribut « Numéro d’élève ».

Slide 47: 

47 Un identifiant d’une entité doit être univalué et non nul : à une occurrence de l’entité correspond une et une seule valeur d’un identifiant; discriminant : à une valeur d’un identifiant correspond une et une seule occurrence de l’entité ; L’entité avec ses propriétés (dont l’identifiant) est schématisée :

II.4 Formalisme : 

48 Exemple Nom de l’association attribut 1 attribut 2 Appartenir II.4 Formalisme

Slide 49: 

49 Pour les entités un nom à chaque entité, les noms de tous les attributs qui la décrivent, schématisées sous forme d’un rectangle divisé en deux parties. Pour les associations un nom à chaque association, les noms de tous les attributs qu’elle porte et des entités qu’elle associe, schématisées sous forme d’un ovale divisé en deux parties et relié aux rectangles.

II.5. Dimension d’une association : 

50 II.5. Dimension d’une association Occurrence d’une association : elle correspond à une et une seule occurrence de chacune des entités associées, l’occurrence de chacun des attributs qu’elle porte correspondant aux occurrences des entités associées. Dimension d’une association : Le nombre d’occurrences d’entités concernées par une occurrence de l’association est appelé sa dimension.

Slide 51: 

51 Exemple 1 : dimension = 2 → association binaire : Exemple 2 : dimension = 3  association ternaire : Avoir pour note note Enseigner Nbre d’heure

Slide 52: 

52 On dit que les entités « élève » et « matière » participent à l’association « avoir pour note ». On dit que les entités « matière » et « professeur » et « classe » participent à l’association « enseigner ».

Slide 53: 

53 Code_prof. Nom_prof. Prénom_prof Statut_prof Professeur Enseigner Nbre_heures Appartenir

III. Contraintes d’intégrité : 

54 III. Contraintes d’intégrité Ce sont les règles relatives aux données qui doivent être incorporées au modèle afin d’assurer la cohérence de la base d’information. Exemple d’incohérence : une commande n’est passée par aucun client; la date de fin de location est antérieure à la date de début de location.

III.1. Cardinalité : 

55 III.1. Cardinalité Définition : les cardinalités d’une entité dans une association mesurent, lorsque l’on parcourt l’ensemble des occurrences de cette entité, le minimum et le maximum de leur participation à l’association. On note (min, max).

Slide 56: 

56 Le formalisme peut être ainsi simplifié : On a quatre types de cardinalité : (0,1) : une occurrence de l’entité ne participe jamais plus d’une fois à l’association ; (1,1) : une occurrence de l’entité participe toujours une et une seule fois à l’association ; (1,n) : une occurrence de l’entité participe toujours au moins une fois à l’association ; (0,n) : aucune précision n’est fournie quant à la participation des occurrences de l’entité à l’association. Avoir pour note -Note 0,n 0,n

III.2. Règles de gestion : 

57 Les règles de gestion du MCD précisent les contraintes d'intégrité qui doivent être respectées par le modèle. Exemple : en plus des règles de gestion R1-R5, le MCD d’une école peut avoir les règles de gestion suivantes : R6 : un professeur fait au moins un enseignement. R7 : une classe a au moins un enseignant. R2 (rappel) : chaque matière est enseignée par un et un seul professeur. Le MCD sera Enseigner Nbre_heures 1,1 1,n 1,n III.2. Règles de gestion

Slide 58: 

58 Avoir pour note Note Code_prof. Nom_prof. Prénom_prof Statut_prof Professeur Enseigner Nbre_heures Appartenir (0,n) (0,n) (1,1) (1,n) (1,n) (0,1) (1,n)

IV. Règles relatives au MCD pour sa mise au propre : 

59 IV. Règles relatives au MCD pour sa mise au propre La mise au propre du MCD s'effectue à travers les opérations suivantes :  la vérification,  la normalisation,

Slide 60: 

60 VI.1 La vérification Règle de non-répétitivité : à toute occurrence de l'entité ou de l'association correspond au plus une valeur de tout attribut qui lui est associé. Règle d'homogénéité : les attributs rattachés à une entité ou à une association doivent avoir un sens pour toutes les occurrences de l'entité ou de la association. Règle de distinguabilité : les occurrences d'une entité doivent être distinguables. Cela induit la compréhension de l'entité et se traduit par le choix de l'identifiant. Règle de normalisation d'une relation : chaque attribut d'une association doit dépendre fonctionnellement de la totalité des entités formant la collection de l'association . Respect des règles de gestion : les règles de gestion relatives aux données, dégagées lors de l'étude de l'existant, doivent avoir été traduites dans le MCD (cardinalités, etc.).

Quelques erreurs de modélisation : 

61 Quelques erreurs de modélisation Cas 1 : Attribut répétitif L'attribut "Matière" peut prendre plusieurs valeurs si le prof. peut enseigner plusieurs matières. Enseigner 1,n 1,n Solution

Quelques erreurs de modélisation : 

62 Quelques erreurs de modélisation Cas 2 : Attribut sans signification L'attribut "Matière" ne prend pas de valeur pour une secrétaire ou un surveillant. Solution

Quelques erreurs de modélisation : 

63 Quelques erreurs de modélisation Cas 3 : Dépendance incomplète Solution Concerner 1,n 1,n Concerner 1,n 1,n Date Qté L'attribut "Date" ne dépend pas du produit et l'attribut "Qté" peut prendre plusieurs valeurs.

Slide 64: 

64 IV. 2. La normalisation du MCD 1ère Forme Normale (1FN) : Tous les attributs doivent être élémentaires par rapport au choix de gestion et il doit y avoir un identifiant à chaque entité. n'est pas 1FN est 1FN

Slide 65: 

65 2ème Forme Normale (2FN) : Tout attribut d'une entité doit dépendre de l'identifiant de cette entité par une dépendance fonctionnelle élémentaire. n'est pas 2FN est 2FN

Slide 66: 

66 3ème Forme Normale (3FN) : Tout attribut d'une entité doit dépendre de l'identifiant par une DF élémentaire et directe. n'est pas 3FN est 3FN

Slide 67: 

67 4ème Forme Normale (4FN) : Si une entité a un identifiant concaténé, un des attributs composant l'identifiant ne doit pas dépendre d'un autre attribut. Exemple : RG1 : tout prof enseigne une et une seule matière. RG2 : toute classe n'a qu'un seul prof par matière. n'est pas 4FN est 4FN

Slide 68: 

68 1FN : élémentarité des attributs et existence de l'identifiant. 2FN : DF élémentaire de l'identifiant. 3FN : DF directe de l'identifiant. 4FN : DF complète de l'identifiant : si l'identifiant est concaténé, un composant ne doit pas être en DF avec un autre attribut.

V. Les étapes pour la construction d'un MCD : 

69 V. Les étapes pour la construction d'un MCD L'étude de l'existant Interview de la direction (Système de Pilotage). Objectifs principaux. Interview des postes de travail (Système Opérant) . Recenser et décrire les tâches exécutées. Observer la circulation des informations. Apprendre le langage de l’entreprise. Etablissement d’une liste des règles de gestion. Construction d’un dictionnaire de données (DD).

Slide 70: 

70 Autres étapes de la construction d'un MCD Epuration du dictionnaire des données (DD) en enlevant  les synonymes (les données identifiées différemment et ayant le même sens); les polysèmes (les données utilisant les mêmes orthographes mais décrivant des réalités différentes) : il faut leur attribuer des noms différents. Construction du GDF (Graphe des Dépendances Fonctionnelles). Extraire du DD la liste des attributs qui ne sont ni concaténés, ni calculés. Transformation du GDF en MCD. Mise au propre du MCD.

Slide 71: 

71 Informatisation du SI d’une société de vente Une société de vente souhaite informatiser son SI actuel (manuel) qui contient essentiellement des données figurant sur des bons de commande ou factures du type : N°Bon …………………… Date …………………… Nom client ……………………………………………………………… Adresse ……………………………………………………………………… …………………………………………………………………………………. Nom représentant ………………………………………… Réf. Design. Qté PU Montant ………… ………… …… ……… ………… ………… ………… …… ……… ………… Total …………

Slide 72: 

72 Elaboration de MCD. On suppose que certaines opérations ont déjà été effectuées : Recueil des informations (interview du SI existant) R1 : un client peut passer une ou plusieurs commandes ou ne passer aucune commande; R2 : une commande concerner au moins un produit; R3 : une commande concerne un et un seul client; R4 : une commande est assurée par un et un seul représentant qui n’est pas toujours le même pour un client donné. Construction d'un dictionnaire de données (DD) :

Slide 73: 

73 Le dictionnaire des données (DD)

Slide 74: 

74 Epuration du dictionnaire des données Les données à ne pas prendre en compte dans un MCD sont, en général, les données calculées et concaténées. Seront supprimées : Adresse, Montant et Total.

Slide 75: 

75 Le graphe des dépendances fonctionnelles NoBon Ref CoCli CoRep Design PU Qté Date NomCli RueCli VilleCli NomRep

Slide 76: 

76 Le graphe des dépendances fonctionnelles NoBon Ref CoCli CoRep Design PU Qté Date NomCli RueCli VilleCli NomRep

Slide 77: 

77 Transformation du GDF en MCD Règles de transformation R1 : les données sources d'au moins une DF (celles qui sont soulignées sur le GDF) représentent les identifiants des entités dont les attributs sont les cibles de ces DF. R2 : Les flèches restantes deviennent des associations. Les données déterminées par une DF conjointe deviennent des attributs portés par l’association. R3 : Les règles de gestion doivent permettre de trouver les cardinalités.

Slide 78: 

78 Qté Application de la 1ère règle (R1)

Slide 79: 

79 Application des règles R2 et R3 CONCERNER Qté PASSER OBTENIR 0,n 0,n 0,n 1,1 1,1 1,n