SI.1 /Introduction aux SI 2012-2013 1.1 Concepts de base 1.1.1 Système Un système est un ensemble d éléments matériels ou immatériels en interaction, organisés en fonction d un objectif. C est un tout constitué d éléments unis par des relations. Ces éléments et ces relations sont munis de propriétés. Donc, "décrire un tel système consiste à déterminer ses éléments, ses relations, leurs propriétés et les valeurs que peuvent prendre ainsi que son activité et l organisation qui en découle" Exemples : - le système "Scolarité" est composé des éléments Professeur, Etudiant, Cours et Département. - les propriétés qui peuvent décrire ces éléments sont par exemple : le matricule du professeur, son nom, le numéro d inscription de l étudiant, le code du cours, son titre, l adresse du département, etc. - les relations entre éléments sont : la relation est rattachée entre Professeur et Département et la relation suit entre Etudiant et Cours. - Les propriétés de ces relations sont du type date d affectation, note, etc. matricule nom Professeur «est rattaché» date affectation Département code adresse N Insc nom Etudiant «suit» note Cours code titre 1.1.2 Système d Information dans l Entreprise L entreprise est un système complexe dans lequel transitent de très nombreux flux d informations. Sans un dispositif de maîtrise de ces flux, l entreprise peut très vite être dépassée et ne plus fonctionner avec une qualité de service satisfaisante. L enjeu de toute entreprise qu elle soit de négoce, industrielle ou de services consiste donc à mettre en place un système destiné à collecter, mémoriser, traiter et distribuer l information (avec un temps de réponse suffisamment bref). Ce système d information assurera le lien entre deux autres systèmes de l entreprise : le système opérant et le système de pilotage. 1
SI.1 /Introduction aux SI 2012-2013 Système de Pilotage information-décision information-représentation Extérieur Système d Information Extérieur information-interaction information-représentation Système Opérant figure 1.1 Sous-systèmes de l organisation Le système de pilotage décide des actions à conduire sur le système opérant en fonction des objectifs et des politiques de l entreprise, Le système opérant englobe toutes les fonctions liées à l activité propre de l entreprise : facturer les clients, régler les salariés, gérer les stocks, etc. Une telle décomposition prend bien en compte : - la différence de besoin en matière d information des modules opérants et pilotes, - la nécessité pour le système d information de ne pas se contenter de transmettre les informations mais d en changer le niveau de synthèse. Dans certaines organisations, on peut trouver des formes plus intégrées du système d information. Cette intégration peut se faire soit au niveau du système opérant (GPAO par exemple), soit au niveau du système de pilotage (SIAD par exemple). 1.1.3 Fonction du Système d Information La prise en charge des informations de l organisation se traduit par : - la collecte d information ; - la mémorisation de l information ; - le traitement de l information ; - la diffusion de l information ; 1.1.4 Système d Information & Système Informatisé Un système d information est une représentation possible du système dont une partie peut être automatisée ; on parle alors de système informatisé. Ce dernier prend appui sur un système informatique composé de matériels et de logiciels de base. 2
SI.1 /Introduction aux SI 2012-2013 1.2 Modèles de Flux d information 1.2.1 Modèles Un modèle est une représentation (souvent graphique) de la réalité et est établi pour répondre à un type de questions que l on se pose sur cette réalité. La notation (symboles) utilisée doit être alors suffisamment précise et riche. Les formalismes normalisés permettent en plus une communication sans ambiguïté. En pratique la modélisation d un système (aspect statique, dynamique et architectural) nécessite l utilisation d une combinaison de types de modèles (modèles de flux d information, modèles de données, modèles de traitements, etc.) pour obtenir une représentation complète du système avec différents niveau d abstraction (conceptuel, organisationnel et technique pour la méthode Merise par exemple). Cette partie du cours présente les modes de représentation des flux d information dans l organisation. 1.3 Flux d Information C est l ensemble des informations échangées entre acteurs et peut être interne, entrant ou sortant du système d information. 1.3.1 Domaines d activités de l organisation Un domaine d activités de l organisation ou poste de travail est un sous-ensemble relativement indépendant constitué d information, de règles et de procédures de gestion. Pour mieux analyser une organisation, il est nécessaire de la découper en domaines d activités indépendants et de mettre en évidence les interactions entre ces domaines (flux internes) ainsi que les échanges avec l extérieur (flux externes). 1.3.2 Graphe de flux d information Ce graphe permet une représentation globale du système, des contraintes (événements) qui lui sont imposées, et des réponses du système à ces contraintes (figure 1.2). demande achat proposition Client commande facture règlement Vente figure 1.2 diagramme de contexte 3
SI.1 /Introduction aux SI 2012-2013 Ce type de modèles peut servir également pour décrire les domaines d activités de l organisation (postes de travail) recevant et générant des flux externes (figure 1.3). demande achat Client proposition commande facture règlement Vente double commande Caissier figure 1.3 graphe de flux d information 1.3.3 Diagramme de Circulation d information (tâche-document) Ce diagramme permet de décrire comment sont réalisées actuellement les procédures et de définir avec précision l ensemble des objectifs recherchés et qui doivent être pris en considération lors de la conception de la solution. 1.3.3.1 Recueil : une série d interviews (ou questionnaires, enquêtes, etc.) des différents intervenants dans l organisation ; la direction (dégager une vue globale du système et l ensemble des objectifs) et les postes de travail (description détaillée du domaine). 1.3.3.2 Formalisme : au fil des interviews, un diagramme tâche-document doit être construit pour permettre de visualiser l enchainement des tâches à travers les documents et/ou les informations qui les déclenchent et ceux qu elles produisent. - La notation utilisée : à donner pendant le cours Exemple : - voir l exemple du cours. 4
SI.2 /Codification et Contrôles 2012/2013 2.1 Concepts de base Les informations traitées par ordinateur doivent être structurées : associer des codes aux informations du système. Ces codes doivent permettre une désignation claire et unique des informations. Exemple. Soit le bon de commande suivant : Bon de commande Numéro commande : Date commande : Numéro client : Nom client : Adresse client : Référence.... Désignation.... Quantité.... Les données qu'on peut extraire de ce document sont : Numéro commande, Date commande, Numéro client, Nom client, Adresse client, Référence produit, Désignation produit et Quantité commandée. Les désignations de ces données sont trop longues et par conséquent très lourdes à manipuler. Le mieux, serait de les abréger sans perdre leurs significations : Numéro commande : Num_Cde Date commande : Date_Cde Numéro client : Num_Cl Nom client : Nom_Cl De l'autre côté, pour différencier les clients, on doit affecter à leurs codes des valeurs différentes : Valeur 1 : 3 ème client dans la région centre Valeur 2 : 8 ème client dans la région est Là encore, les données sont longues et, encore, on doit chercher à les abréger. Pour cela, nous allons représenter ces données par un code comme suit : Région (C, E, O) Numéro du client par région Valeur 1 : Num_Cl = C003 5
SI.2 /Codification et Contrôles 2012/2013 Valeur 2 : Num_Cl = E008 La codification porte sur le Nom de l'information à codifier et aussi sur sa Valeur, et : - ne doit pas être ambiguë (Num_C?), - doit s'adapter aux changements du système (Client numéro 1001 de la région Ouest?), - doit être concise et significative. 2.2 Types de codification Il existe différents types de codification : séquentielle, par tranches ou articulée. 2.2.1 Codification séquentielle Les numéros attribués aux informations sont consécutifs (1, 2, 3, ). C'est une codification très simple et non ambiguë, mais non significative et insertion impossible (sauf réutilisation). 2.2.2 Codification par tranches Attribuer une tranche de codes à chaque catégorie d'objets à codifier (0-999 : info, 1000-1999 : math, 2000-2999 : physique, ). La codification est très simple et non ambiguë, mais non significative et insertion impossible si le nombre d'informations à codifier dépasse l'intervalle des codes prévus. 2.2.3 Codification articulée Attribuer des codes découpés en zones appelées descripteurs. Chaque descripteur a une signification particulière relative à l'élément codifié. Exemple. Immatriculation d'un véhicule : 0 0 2 1 5 1 0 5 1 9 Numéro séquentiel Catégorie Année Code wilaya Significative et non ambiguë, insertion et extension possibles, mais les codes sont trop longs, possibilité de saturation et instabilité. 2.2.4 Codification par niveau C'est un cas particulier de la codification articulée dans lequel les descripteurs sont des niveaux. Exemple. Code postal : 1 6 3 2 0 Code wilaya Daïra Commune 6
SI.2 /Codification et Contrôles 2012/2013 2.2.5 Codification mnémonique Associer au nom de l'élément, un nom abrégé qui rappelle l'élément codifié (code postal : C_P). C'est une codification simple et significative. Elle porte, cependant, sur le nom et non pas sur la valeur. 2.3 Contrôles L'objectif des opérations de contrôle est de vérifier l'exactitude et la conformité de l'information. Exemple. Numéro étudiant dont la spécialité n'existe pas. Les contrôles peuvent être directs; effectués sur l'information sans tenir compte des autres informations du système, ou indirects; vérifier la conformité de l'information par rapport à l'ensemble des informations du système. 2.3.1 Contrôles directs Les principaux contrôles directs sont : - Contrôle de présence ou de non présence (abonné/nouveau); - Contrôle de type; - Contrôle de cadrage (position de l'information dans la zone de saisie). 2.3.2 Contrôles indirects Parmi les contrôles indirects, on peut citer : - Contrôle de cohérence interne (Numéro_Etud = Li.4.175 : année pour licence 3); - Contrôle de cohérence externe (DateNais = 1970 et Âge = 63); - Contrôle de vraisemblance (Date_Cde = 15/13/09 : mois 12). 7
SI.3 /Merise 2012/2013 3.1 Démarche de développement de systèmes logiciels Le groupe d'étude (Project group) Un système d'information qui n'est pas trop complexe et volumineux en termes d'informations, peut facilement être informatisé par une seule personne. Il suffit d'être un peu familiarisé avec une méthode de modélisation, et de savoir manipuler un SGBD pour réaliser une implémentation informatique, cohérente et fonctionnelle, d'un tel système d'information. Dès que le système d'information atteint une certaine envergure (par exemple: informatiser la gestion des sinistres d'une compagnie d'assurances), un groupe d'étude est généralement créé. Ce groupe doit contenir en plus des informaticiens : Un ou plusieurs représentants des futurs utilisateurs du système informatisé (Par exemple: Un employé du service qui gère les sinistres) ; Un ou plusieurs représentants de chaque département impliqué (Par exemple: Un employé du service des contrats) ; Un représentant de la direction. Généralement, un responsable du groupe ( Project Manager) est nommé, afin de coordonner les travaux effectués par le groupe et de suivre le déroulement à partir de l'analyse jusqu'à la mise en place du système informatisé. Les étapes Chaque projet d'informatisation, qu'il soit exécuté par une seule personne, ou géré par un groupe d'étude, prévoit plusieurs étapes. En général, les principales étapes sont : 1. Analyse de la situation existante et des besoins; 2. Création d'une série de modèles qui permettent de représenter tous les aspects importants; 3. Implémentation du système logiciel correspondant. Sources d'information La première étape de chaque projet est donc l'analyse de l'existant et des besoins. Donc, il faut d'abord identifier les sources d'information, et puis rassembler les informations importantes pour le projet. Les principales sources d'information sont : L'interview avec les utilisateurs; Documents provenant du système d'information actuel (Bons de commandes, Factures ). 12
SI.3 /Merise 2012/2013 Pour les projets d'une certaine envergure s'ajoute : L'interview avec les responsables des services impliqués; Pour les projets qui se basent sur un système déjà partiellement informatisé s'ajoute: L'étude de l'application informatique existante. 3.2 Merise Nous avons vu que la démarche classique d'un projet informatique comprend les étapes suivantes: 1. Analyse de la situation existante et des besoins; 2. Création d'une série de modèles, qui permettent de représenter tous les aspects importants; 3. A partir des modèles, implémentation d'une base de données. En ce qui concerne la première étape, nous n'allons pas introduire de vraies règles, mais simplement utiliser nos connaissances de gestion d'une entreprise, notre esprit ouvert et même notre fantaisie pour analyser correctement la situation existante et les besoins des utilisateurs. Le résultat de l'analyse est généralement un ou plusieurs documents, qui contiennent les indications principales sur le fonctionnement désiré du système informatisé. Le document d'analyse contient souvent déjà des prototypes de certains documents importants, que le futur système devra être capable de produire. Une fois que l'analyse est terminée, il s'agit d'élaborer une série de modèles, basés sur le document d'analyse. Ces modèles nous permettront plus tard d'implémenter une application qui répondra à tous les besoins fonctionnels du système. La création de ces modèles se fait selon une certaine méthode. Nous allons baser notre cours sur la méthode MERISE (Méthode d'etude et de Réalisation Informatique de Systèmes d'entreprise), qui a été développée pendant les années 70. C'est une méthode systémique qui sépare les données des traitements, prévoit une conception par niveaux, et définit pour cela 3 niveaux essentiels : 1. Le niveau conceptuel, qui se base directement sur l'analyse, décrit l'ensemble des données et des traitements du système d'information, sans tenir compte de l'implémentation informatique de ces données ni des détails organisationnels et techniques des traitements (quoi?). Ce niveau se traduit par deux modèles conceptuels que nous appelons : Modèle conceptuel des données (MCD) et Modèle conceptuel des traitements (MCT). 2. Le niveau logique, qui se base sur le modèle conceptuel, prend en considération la technique d'organisation de données et les détails organisationnels des traitements (qui, où et quand?). Ce niveau est représenté par les : Modèle logique des données (MLD ) et Modèle organisationnel des traitements (MOT). 13
SI.3 /Merise 2012/2013 3. Le niveau physique, qui se base sur les modèles du niveau précédent, contient finalement tous les détails d'implémentation du système de données et des traitements (comment?). Ce niveau est représenté par les : Modèle physique des données (MPD ) et Modèle opérationnel des traitements (MOpT). Voici donc les étapes nécessaires pour automatiser un système d'information : Analyse MCD MCT Validation MOT MCD validé MLD La validation MPD MOpT Définir les données d'une application de manière complètement indépendante des traitements conduit nécessairement à un échec global. En faite, les traitements utilisent, manipulent et produisent des données. Donc, il serait indispensable de valider le modèle de données par les traitements avant de passer à l'implémentation. Cette validation vise à rajouter les données nécessaires (qui ne sont pas encore définies dans le MCD) et de supprimer les données inutiles (qui sont définies dans le MCD mais qui ne sont utilisées par aucun traitement). 14
SI.4 /Modèle Conceptuel de Données 2012/2013 4.1 Définition En se basant sur un document d'analyse, le modèle conceptuel des données (MCD) fait référence à tous les éléments du système d'information et aux relations entre ces éléments. Le formalisme utilisé dans ce modèle est connu sous le nom de "Schéma Entité-Relation". Ce formalisme se base sur trois concepts principaux, les entités, les relations et les propriétés. Entité Propriété Relation Voici par exemple un MCD qui représente une entreprise avec ses employés. 4.2 Concepts de base a. Entité (individu ou objet). Une entité permet de modéliser un ensemble d'objets concrets ou abstraits de même nature. Une entité est caractérisée par son nom et ses propriétés. Exemple : Employé, entreprise, Etudiant, Cours, etc. Représentation graphique : Voici un exemple de l'entité Etudiant : Etudiant Num_Etudiant Nom_Etudiant DN_Etudiant Adr_Etudiant 15
SI.4 /Modèle Conceptuel de Données 2012/2013 Chacun des étudiants suivants représente une occurrence de l'entité Etudiant. :Etudiant 017 Ahmed 12/03/94 Sétif :Etudiant 095 Omar 06/02/94 El-Eulma :Etudiant 129 Fatima 31/05/95 Sétif b. Propriété. Une propriété est une donnée élémentaire d'une entité. Elle est unique dans un MCD; et ne peut pas être rattachée à plusieurs entités différentes. Une propriété est caractérisée par : son type (Numérique, Alphabétique, etc.), sa longueur (taille en caractères), et sa nature (élémentaire, calculée ou concaténée). Exemple : Nom de l'étudiant, Adresse de l'étudiant, etc. A l'intérieur de chaque occurrence, chaque propriété prend une valeur, qui est dans la plupart des cas une valeur numérique, une valeur sous forme de texte ou encore une date. Exemple : La propriété Nom_Etud de l'entité Etudiant prend par exemple les valeurs "Ahmed", "Omar" et "Fatima" dans les 3 occurrences de l'exemple précédent. A l intérieur de chaque occurrence, chaque propriété ne prend qu une seule valeur au maximum. Exemple : L'étudiant 095 ne peut pas avoir 2 adresses. c. Identifiant Afin de pouvoir distinguer les différentes occurrences d'une même entité, l'entité doit être dotée d'un identifiant. Chaque occurrence de l'entité doit avoir une valeur différente pour l identifiant. Le choix de l'identifiant repose sur 3 possibilités: 1. Une propriété naturelle Exemple: Le nom d'un pays pour une entité Pays 2. Une propriété artificielle qui est inventée par le développeur du MCD Exemple: Le numéro d'un étudiant (Num_etud) 3. Une propriété concaténée (composée d'autres propriétés naturelles) Exemple: Le nom et la localité pour une entité Entreprise (NomEntr_NomVille) 16
SI.4 /Modèle Conceptuel de Données 2012/2013 Dans le formalisme utilisé, l'identifiant d'une entité est une propriété soulignée en tête de l'ensemble des propriétés. d. Relation. Une relation décrit un lien entre deux ou plusieurs entités (collection de la relation). Elle possède un nom, généralement un verbe à l'infinitif. L'existence de la relation est conditionnée par celle des entités qui participent à cette relation. La relation n'a pas d'identifiant propre, mais elle est implicitement identifiée par la concaténation des identifiants des entités qui participent à cette relation. 1. Dimension d'une relation : c'est le nombre de pattes de la relation. Le nombre de pattes n'est pas nécessairement identique au nombre d'entités. Il représente plutôt le nombre d'occurrences d'entités qui doivent participer à une occurrence de la relation. Nous distinguons des relations : binaires, qui possèdent 2 pattes; ternaires, qui possèdent 3 pattes; n-aires, qui possèdent n pattes. Exemple d'une relation binaire: 2. Cardinalités d'une relation Une relation est liée à chacune de ses entités par une ou plusieurs pattes. Sur la patte, on indique les cardinalités qui précisent le nombre de participations de chaque occurrence de l'entité à la relation. Le premier nombre indique la cardinalité minimale, le deuxième la cardinalité maximale. Patte Cardinalité minimale Cardinalité maximale 17
SI.4 /Modèle Conceptuel de Données 2012/2013 Exemple : Dans cet exemple, entre l'entité Client et la relation Passer, nous avons les cardinalités suivantes: Cardinalité minimale = 1, ce qui signifie que chaque client passe au moins une commande. Cardinalité maximale = n, ce qui signifie que chaque client peut passer plusieurs (n) commandes. Entre l'entité Commande et la relation Passer, nous retrouvons les cardinalités suivantes: Cardinalité minimale = 1, chaque commande est passée par au moins un client. Cardinalité maximale =1, chaque commande est passée au maximum par un seul client. De façon générale, quatre types sont distingués : 0,1 : chaque occurrence participe au plus une seule fois à la relation. 1,1 : chaque occurrence participe une et une seule fois à la relation. 1,n : chaque occurrence participe au moins une fois à la relation. 0,n ; aucune précision n'est donnée quant au nombre de participations. Comme cas particulier, la modélisation suivante par exemple n'est pas correcte: Dans ce cas, il faut réunir les propriétés des deux entités dans une seule. 18
SI.4 /Modèle Conceptuel de Données 2012/2013 3. Propriétés d'une relation Une relation peut généralement être porteuse de propriétés. Exemple: f. Règles de gestion Les règles de gestion précisent les contraintes qui doivent être respectées par le modèle. Exemples : pour un magasin, Une personne habite dans une et une seule maison; Plusieurs personnes peuvent habiter dans la même maison; Une personne peut être propriétaire de plusieurs maisons; Pour une maison, nous avons au moins un propriétaire. Les règles de gestion expriment les contraintes d'intégrité du modèle (les lois de l'univers réel modélisé dans le SI). 4.3 Cas particuliers du MCD a. Plusieurs relations différentes entre deux entités Il est possible d'avoir plusieurs relations différentes entre deux mêmes entités. Chacune de ces relations possède évidemment une sémantique différente. Le rôle de l'entité diffère alors d'une relation à une autre. Exemple : Une personne, peut être l'habitant d'une maison et/ou le propriétaire de la maison. Ici, habitant et propriétaire sont des rôles joués par l'entité Personne. 19
SI.4 /Modèle Conceptuel de Données 2012/2013 b. Relation réflexive et rôle d'une patte de relation Exemple : Une relation réflexive, est une relation, dont les deux pattes sont liées à une même entité. En général, la signification des pattes d'une relation réflexive devrait être clarifiée par l'indication d'un rôle. Nous avons donc: 4.4 Dépendances fonctionnelles 4.4.1 Définition Les propriétés a et b sont reliées par une dépendance fonctionnelle a df b, si la connaissance de la valeur de a détermine une et une seule valeur de b. Exemple : Num_Etud df Nom_Etud. La dépendance fonctionnelle peut porter sur la concaténation de plusieurs propriétés. Exemple : NumCommande + RéfProduit df QtéCommandée. 4.4.2 Dépendance fonctionnelle élémentaire Il y a dépendance fonctionnelle élémentaire entre les propriétés a et b et on note a b, si a df b et aucune partie de a ne détermine b. 20
SI.4 /Modèle Conceptuel de Données 2012/2013 Exemple : Num_Etud+Nom_Etud df Adr_Etud n'est pas élémentaire puisque la connaissance de Num_Etud suffit pour déterminer Adr_Etud. Par contre, Num_Etud df Adr_Etud est élémentaire et on note Num_Etud Adr_Etud. 4.4.3 Dépendance fonctionnelle élémentaire directe Les propriétés a et b sont reliées par une dépendance fonctionnelle élémentaire directe si ab et s'il n'existe pas une propriété c telle que a df c et c df b. autrement dit, on élimine toute transitivité. Exemple : NumProf CodeMatière CodeMatière NomMatière NumProf NomMatière. Les deux premières dépendances fonctionnelles sont directes, mais la troisième ne l'est pas : transitivité NumProf CodeMatière NomMatière. 4.4.4 Clé d'une entité Toutes les propriétés d'une entité doivent dépendre fonctionnellement de sa clé et ceci n'est plus vrai pour aucune des parties de cette clé. Exemple 1 : Num_Etud+Nom_Etud n'est pas une clé puisque Num_Etud détermine Adr_Etud. En revanche, Num_Etud est une clé car : Num_Etud df Nom_Etud Num_Etud df Adr_Etud 4.4.5 Propriétés des dépendances fonctionnelles Réflexivité : Projection : Augmentation : Additivité : Transitivité : Pseudo-transitivité : a df a a df b+c a df b et a df c a df b a+c df b a df b et a df c a df b+c a df b et b df c a df c a df b et b+c df d a+c df d 21
SI.4 /Modèle Conceptuel de Données 2012/2013 4.5 Règles relatives au MCD Tout MCD doit être normalisé, vérifié et décomposé. 4.5.1 Normalisation des entités Les entités du MCD doivent vérifier les règles suivantes : a. 1 ère forme normale : dans une entité, toutes les propriétés sont élémentaires et il existe au mois une clé caractérisant chaque occurrence (identifiant). Exemple : (voir exemple du cours) b. 2 ème forme normale : toutes les propriétés d'une entité doivent dépendre de la clé par une dépendance fonctionnelle élémentaire. Exemple : (voir exemple du cours) c. 3 ème forme normale : dans une entité, les propriétés doivent dépendre de la clé par une dépendance fonctionnelle élémentaire directe. Exemple : (voir exemple du cours) d. forme normale de Boyce-Codd (BCNF) : si l'entité possède un identifiant concaténé, un des éléments composant cet identifiant ne doit pas dépendre d'une autre propriété. Exemple : (voir exemple du cours) L'objectif de la normalisation est d'éliminer la redondance (répéter la désignation du produit commandé à chaque commande du même produit) et les anomalies de mise-à-jour (annuler employé annuler catégorie) 4.5.2 Vérification Dans toute occurrence d'entité ou de relation, il ne doit y avoir qu'une seule valeur de chaque propriété. Pour les entités ceci résulte de la première forme normale. Exemple : (voir exemple du cours) "Les propriétés d'une relation doivent dépendre fonctionnellement des identifiants des entités concernées par la relation. La concaténation de ces identifiants forme l'identifiant de la relation." 4.5.3 Normalisation des relations Chaque propriété d'une relation doit dépendre fonctionnellement de l'ensemble des identifiants des entités de la collection de cette relation, mais d'aucun sous-ensemble. Exemple : (voir exemple du cours) 22
SI.4 /Modèle Conceptuel de Données 2012/2013 4.5.4 Décomposition des relations La décomposition consiste à remplacer une relation de dimension n (supérieure à 2) en plus ieurs relations de dimensions plus petites en utilisant les dépendances fonctionnelles présentes sur la relation. La décomposition n'est possible que si les deux conditions sont vérifiées : 1. Cardinalité minimale des entités à gauche de la dépendance fonctionnelle doit être 1 dans la relation à décomposer; 2. Si la dépendance fonctionnelle provient d'une autre relation, il faut qu'elle concerne les mêmes occurrences d'entités que la relation à décomposer. Exemple : (voir exemple du cours) 4.6 Démarche de construction du MCD 1. Etablir la liste des données recensées : cette liste est appelée dictionnaire de données. 2. Epurer le dictionnaire de données : ne garder que les données utiles pour le SI. De ce fait, les synonymes, les polysémies, les données calculées et les données concaténées doivent être supprimées. Le formalisme du DD est le suivant : Code Désignation Type Taille Observation Code_F Numéro du fournisseur N 3 Nom_F Nom du fournisseur A 20 Adr_F.... Date_Cde Date de la commande Date.......... 3. Etablir le graphe des dépendances fonctionnelles (structure d'accès théorique) : à partir des règles de gestion. a. Il ne faut garder que les dépendances fonctionnelles élémentaires directes, b. S'il reste des propriétés isolées, proposer des identifiants qui permettent de les déterminer. 4. Construire le MCD : a. Les arcs terminaux d'une même origine Entité, b. Les arcs restants qui relient deux ou plusieurs entités traduisent des relations entre ces entités, c. Tenir compte des règles de gestion qui ne sont pas encore couvertes (celles qui n'expriment pas de dépendances fonctionnelles), d. Normaliser, vérifier et décomposer le MCD brut 23
SI.4 /Modèle Conceptuel de Données 2012/2013 5. Quantifier le MCD : description des entités et des relations. a. Description des entités : Entité Identifiant Propriétés Longueur Nombres occurrences.. b. Description des relations : Relation Entités Cardinalités Propriétés Longueur Nombres d'occurrences.. 24
SI.5 /Modèle Conceptuel des Traitements 2012/2013 5.1 Objectifs Dégager les actions menées par l entreprise, indépendamment de la façon dont cette dernière a choisi de les organiser. Le MCT exprime ce qu il faut faire(le Quoi), mais n indique pas Qui, Quand et Où (Concepts Organisationnels) ni Comment il faut le faire (Concepts Opérationnels). 5.2 Définitions 1. Evénement : traduit un fait nouveau dans le système qui peut être déclencheur (ex. arrivée d une commande) ou résultat (ex. facture établie) d une opération du SI. Ce fait est porteur d information. 2. Opération : ensemble d actions accomplies en réaction à un événement ou à une conjonction d événements déclencheurs et produit en sortie de nouveaux événements. L enchainement des actions dans une opération conceptuelle est ininterruptible et toute attente d un événement externe provoque un découpage de l opération. 3. Synchronisation : c est la représentation d une pré-condition au déclenchement d une opération ; c est une association d événements. L opération est déclenchée après arrivées des événements contributifs selon une proposition logique (OU et ET). 4. Règle d émission : condition traduisant les règles de gestion, auxquelles est soumise l émission des résultats d une opération. Ces règles doivent couvrir l ensemble des situations possibles de façon que l opération émette toujours un résultat. 5. Processus : c est un enchaînement d opérations propre à un domaine d activités. C est un sous-ensemble d activités dont les points d entrée et de sortie sont stables et indépendants des choix organisationnels. 5.3 Formalisme Le formalisme utilisé est le suivant : Event 1 Event n Synch Nom Opération Liste actions Règle émission 1 Règle émission 2 R 1 R j 5.4 Exemple (voir exemple du cours) 25
SI.6 /Modèle Organisationnel des Traitements 2012/2013 6.1 Objectifs Fournir une représentation schématique de l organisation du SI en répondant aux questions : Où? : le poste de travail concerné. Qui? : nature du traitement manuel ou automatisé (batch ou conversationnel). Quand? : le temps et la durée (déroulement). Merise n impose aucun choix organisationnel. La méthode offre simplement des outils permettant de décrire l organisation retenue. 6.2 Définitions 1. Règle d organisation : ce qui est mis en place en termes de poste de travail, de nature de traitement et de chronologie. 2. Evénement : fait réel dont l occurrence déclenche une ou plusieurs procédures fonctionnelles (ex. arrivée déclaration sinistré). 3. Procédure fonctionnelle : ensemble d actions de même nature accomplies dans un poste de travail en réaction à un déclencheur de manière continue et complète. 4. Synchronisation : condition logique traduisant les règles de gestion et d organisation que doivent vérifier les événements pour déclencher les procédures. Le déroulement (temps et durée) fait partie intégrante de la synchronisation (ex. demande inscription et début année) 5. Règle d émission : condition traduisant les règles de gestion et d organisation, auxquelles est soumise l émission des résultats d une procédure. 6.3 Formalisme Le formalisme utilisé est le suivant : Déroulement Enchaînement des Procédures Fonctionnelles Nature Poste de travail Event 1 Event n Synch Nom Procédure Liste actions Règle émission 1 Règle émission 2 R 1 R j 6.4 Exemple (voir exemple du cours) 26
SI.7 /Validation du MCD 2012/2013 7.1 Introduction Chaque traitement possède son modèle externe (vue externe) qui reflète la vision que possède l utilisateur des données à travers la procédure (procédure fonctionnelle automatisée). C est un MCD construit dan l optique d un seul traitement sans se préoccuper du MCD réel. La validation permettra d ajuster MCD et vues externes (mettre en accord données et traitements). 7.2 Formalisme Utilisation du formalisme entités/relations. Cependant, L identifiant n est pas obligatoire et utilisation du vocabulaire du dictionnaire de données pour les propriétés externes qui correspondent à des propriétés conceptuelles. 7.3 Construction des ME Construire une vue externe pour chaque traitement de consultation ou de mise-à-jour d une même procédure fonctionnelle automatisée : o o Consultation : à partir des données produites Mise-à-jour : à partir des données entrantes Une PF peut avoir donc plusieurs modèles externes. Appliquer les règles de normalisation, vérification et décomposition Les propriétés, entités ou relations externes peuvent ne pas exister dans le MCD 7.4 Validation du MCD Les principales étapes de validation sont les suivantes : Valider les ME en consultation ; ajouter les propriétés externes qui ne sont pas encore définies dans le MCD. Toute modification du MCD implique une réévaluation des ME Valider les ME en m-à-j de la même manière Toute propriété conceptuelle est manipulée dans une vue externe au minimum Supprimer du MCD toutes les propriétés conceptuelles qui ne participent à aucune vue externe Construire le MCD validé en tenant compte des modifications apportées. 27
SI.8 /MLD 2012/2013 8.1 Introduction Jusqu'à présent nous avons établi des MCD basés sur une analyse d'un domaine bien défini. La finalité d'un MCD est de nous faciliter la création d'un système de données pour gérer un tel domaine. Au niveau organisationnel, il faut intégrer les choix d'organisation (gestion des données) et transcrire le MCD validé dans un formalisme dépendant du choix organisationnel sans tenir compte des techniques de stockage et d'accès (niveau opérationnel). L'organisation peut être relationnelle (bases de données), navigationnelle (fichiers), Hiérarchiques, etc. Le modèle logique des données contient donc, toutes les informations du MCD, et les représente à l'aide d'un formalisme différent qui tient compte de la manière dont les données du système sont organisées. 8.2 Contexte relationnel Raisonner en termes de relations qui existent entre les différentes propriétés (ne pas confondre avec les relations du modèle conceptuel qui expriment des associations entre entités. Voici un exemple qui montre un MCD avec son MLD relationnel correspondant: Le MLD correspondant : AUTEUR (No_Auteur, Nom) LIVRE (No_Livre, titre, No_Auteur) 8.3 Règles de passage du MCD au MLD relationnel Nous allons définir les règles de transformation pour le passage du MCD au MLD relationnel, en respectant les différents cas qui se posent. Les entités deviennent des relations au sens relationnel (leurs propriétés deviennent des constituants de la relation) Une relation R du MCD du type : A 0,n ou 1,n R 0,1 ou 1,1 B disparaît dans le MLD. L'identifiant de A étant incorporé à la relation B (au sens relationnel) 28
SI.8 /MLD 2012/2013 Une relation R du MCD du type : A 0,n ou 1,n R 0,n ou 1,n B devient une relation relationnelle dans le MLD. La clé étant obtenue de la concaténation des identifiants des entités qui participent à la relation conceptuelle. Si R est porteuse de propriétés, celles-ci deviennent des constituants de la relation relationnelle. Cas particuliers Un MCD du type : A 0,1 ou 1,1 Se traduit de la manière suivante : A (Id_A,., Id_B) avec B (Id_B, ) ou A(Id_A, ) avec B (id_b,,id_a) R 0,1 ou 1,1 B Les Relations réflexives du type : 1,n R se traduit comme suit : A (id_a,., Id_A) A 1,1 On applique les règles générales avec la seule différence que la relation est 2 fois reliée à la même entité. Application. Pour le MCD suivant : Voici le MLD relationnel correspondant : CLIENT (No_Client, Nom, Prénom, Adresse, Code_Postal, Localité) FACTURE (No_Facture, Date, No_Client) ARTICLE (No_Article, Libellé, Prix_Unitaire) PORTER (No_Facture+No_Article, Quantité) 29