Bases de données PDF

Bases de donnée Hicham BEHJA  Plan I. Définition d’un système d’information II. Méthodologies et méthode de conception III. Modèle relationnel IV. Langage SQL 2  Système d'Information (SI)  Toute organisation peut être cons...

Bases de donnée Hicham BEHJA  Plan I. Définition d’un système d’information II. Méthodologies et méthode de conception III. Modèle relationnel IV. Langage SQL 2  Système d'Information (SI)  Toute organisation peut être considérée comme un système traitant des flux physiques et des flux d'informations  Un SI peut être considéré comme un ensemble de flux d'informations, d'opérations qu'ils subissent et de moyens mis en œuvre pour ce faire quelle que soit la nature de ces moyens.  L'entreprise est un système ouvert sur son environnement avec lequel il échange des flux de produits, de personnels et d'argent impliquant tous corrélativement des flux d'informations 3  Système d'Information  Chacune des trois grandes catégories de flux : produits, personnel et argent est traitée à l'intérieur du « système entreprise » par des sous-systèmes assurant des fonctions spécifiques.  On distingue – les systèmes logistiques et de production – les systèmes de marketing – les systèmes comptable et financier – les systèmes de contrôle et de planification stratégique –...  Pour chacun de ses sous-systèmes on peut mettre en évidence les principaux SI qu'ils impliquent 4  Définir «Système d'Information» Définir un SI : « une entreprise délicate » – SI = Véhicule de communication de l'organisation dont il assure l'information interne et externe. Le langage de cette communication est constitué par les données. – SI = Ensemble des moyens humains, matériels et méthodes se rapportant au traitement des différentes formes d'information rencontrées dans les organisations – Un SI peut être constitué de procédures manuelles ou automatisées 5  Définition d'un système Un système est un ensemble d'éléments : – dotés d'une structure, – en interaction entre eux et avec l'environnement, – qui réalise des fonctions, – qui transforme la matière, – de l'énergie ou de l'information, – qui évolue dans le temps, – selon un objectif. 6  SYSTEME DE PILOTAGE Coordination, objectifs (membres de la direction, …) Décisions Décisions l ’extérieur Informations vers Informations traitées SYSTEME D ’INFORMATION Informations - Collecte - Mémorisation externes des données - Traitement - Transmission FLUX Informations collectées FLUX ENTRANT SYSTEME OPERANT SORTANT Production, action (ensemble du personnel exécutant) 7 Rôle d'un Système d'Information Collecter des informations provenant : - d ’autres éléments du système - de l’environnement Mémoriser des données : -base de données -Fichiers -Historique, Archivage Traiter les données stockées : -traitements automatisables -aide à la prise de décision Communiquer 8 Le Cycle de Vie d'un Logiciel 1. Définition du cycle de vie 2. Étapes de la vie d’un logiciel 3. Cycle de la cascade 4. Cycle en V 5. Cycle en Y 6. Cycle en spirale 7. Cycle par incréments 9  Développement logiciel : un processus complexe Le développement de logiciel n'est pas simplement l'écriture de programmes sur une durée variant de quelques heures à quelques jours : – c'est un processus beaucoup plus complexe auquel on applique le : «diviser pour régner», qui permet de le maîtriser en le divisant en sous-tâches 10  Etapes de la vie d'un logiciel  La structure des logiciels suit une progression logique – Etude du problème (analyse conceptuelle) – Etude d'une solution (analyse logique) – Etude technique détaillée (design et analyse physique) – Codage – Tests – Utilisation (Mise en exploitation) – Maintenance et Evolution  Cet ensemble d'éléments se traduit par le cycle de vie d'un logiciel 11  Cycle de vie : définitions Le cycle de vie d'un logiciel est la période située entre le début de la conception et l'arrêt de l'exploitation de ce logiciel. « Le cycle de vie regroupe un ensemble d'activités suivant les normes AFNOR Z 67 150. Il est envisagé à un instant donné et va comprendre les progrès technologiques et les contraintes organisationnelles » (A. Carlier, 1994) Le cycle de vie d'un logiciel « correspond à l'identification des états successifs d'une application ou d'un produit déterminé. Il est essentiellement dynamique, évolutif et presque toujours progressif » (A. Carlier, 1994) 12  Les différentes phases du cycle de vie d’un développement logiciel Expression des besoins  Description informelle des besoins exprimés par l’utilisateur – Fonctionnels Fonctionnalités attendues du système – Techniques (pouvant déboucher sur du prototypage) moyen d’accès (local, distant, Internet...) temps de réponse acceptable quantité d’informations à stocker  Produit un cahier des charges 13  Les différentes phases du cycle de vie d’un développement logiciel Analyse  Description formelle du problème (Quoi) Phase essentielle dans le cycle de vie du logiciel, souvent négligée (à tort !) car les conséquences d’une analyse bâclée sont toujours très coûteuses  Nécessite de bonnes connaissances métier Exploitation de la capture des besoins nécessitant l’implication des utilisateurs et de la maîtrise d’ouvrage  Produit les spécifications 14  Analyse des besoins Le but de cette activité est d'éviter de développer un logiciel non adéquat. Entrée: données fournies par des experts du domaine d'application et les futurs utilisateurs Méthodes: entretiens, questionnaires, observations de l'existant, études de situations similaires (sciences cognitives) Résultat: documents décrivant 15  Analyse des besoins  l'environnement du futur système  son rôle  son utilisation (manuel d'utilisation préliminaire)  si nécessaire, partage entre matériel et logiciel  Essentiellement au début du processus de développement.  Faite en coordination avec les études de faisabilité et la planification.  Peut se poursuivre durant tout le cycle de vie (maintenance évolutive). 16  Les différentes phases du cycle de vie d’un développement logiciel Conception  Recherche de solutions tenant compte de l’Architecture technique (Comment)  2 phases – Conception Préliminaire (ou générale) Fusion de l’analyse des besoins fonctionnels et techniques Définition de l’Architecture technique générale – Conception Détaillée Raffinage des modèles d’Analyse Préparation au codage dans le langage cible  Produit un dossier de Conception préliminaire et un dossier de Conception détaillée 17  Spécification globale  La spécification globale a pour but d'établir une description du futur système.  Entrée: analyse des besoins + considérations techniques et faisabilité informatique  Méthodes: SADT, SART, MERISE,...  Résultat: modèle conceptuel  ce que doit faire le futur système; QUOI et non comment  complément au manuel d'utilisation  manuel de référence préliminaire  Souvent regroupée dans la même étape que la spécification des besoins. Cette activité ne fait pas apparaître de choix d'implémentation. 18  Conception architecturale, détaillée Le but de la conception architecturale détaillée est d'établir une description très proche du système à réaliser. Entrée: les spécifications globales + contraintes d'implémentation Méthodes: enrichir la description du système de détails d'implémentation. Deux étapes: 1. conception architecturale décomposer le logiciel en composants plus simples en terme de fonctions et interface architecture du logiciel et spécification des composants 19  Conception architecturale, détaillée 2. conception détaillée description de chaque composant: algorithmes, structure des données,...  Résultat: modèle d'implémentation: architecture du système spécification des composants algorithmes modèle des données (entité-association) selon la nature de la conception:  Fonctionnelle: modèles par flux de données: DFD, Contexte, AFD, structure, Petri,...  Objets: diagrammes UML...  Peut remettre en cause les spécifications globales. 20  Les différentes phases du cycle de vie d’un développement logiciel Développement  Production du code associé – les diagrammes élaborés doivent être suffisamment complets pour que le développeur ne se pose pas de question ayant trait à l’analyse ou à la conception – éventuellement, utilisation d’un générateur de code « intelligent »  attention : l’opportunité d’un générateur de code devra être étudiée au début de la phase de Conception  Tests unitaires – Tests « boîte blanche » des unités élémentaires de code  Produit le code et le dossier de tests unitaires 21  Programmation  Cette activité consiste à passer du résultat de la conception détaillée à un ensemble de programmes ou de composants logiciel. Elle est la mieux outillée et maîtrisée. Dans certain cas elle peut être totalement automatisée.  Entrée: conception détaillée + contraintes de l'environnement de programmation  Méthodes: Dans certains cas, cette étape peut être automatisée (génération automatique de code)  Résultat: documents décrivant:  code source  directives: compilation, liens,...  documentation d'implémentation 22  Les différentes phases du cycle de vie d’un développement logiciel Intégration  Assemblage des différents composants constituant le système – Vérification du respect des interfaces inter-composant – Vérification de type « boîte blanche » Validation  Recette du système par le client – Vérification du respect des interfaces inter-composant – Vérification de type « boîte noire » 23  Validation et vérification Le but de cette activité est de s'assurer de l'adéquation du système produit face aux besoins et spécifications: - validation: spécifions-nous le bon système c'est à dire un système correspondant aux attentes des utilisateurs et respectant les contraintes de leur environnement? - vérification: le système réalisé correspond-il aux spécifications? 24  Validation et vérification Entrée: documents produits par l'ensemble des étapes précédentes Méthodes: - validation: revues et inspections des spécifications, manuels, prototypes - vérification: examens des spécifications, programmes, preuves, tests 25  Les différentes phases du cycle de vie d’un développement logiciel Exploitation Déploiement du système Mise en production Maintenance Correction des anomalies Prise en compte des demandes d’évolutions 26  Activités de développement  Les activités relevant du génie logiciel sont maintenant bien définies. Nous trouvons: – l'analyse des besoins; – la spécification globale; – la conception architecturale et détaillée – Développement – Intégration – Validation – Exploitation et maintenance  La spécification et la conception représentent environ 40% de l'effort dans un projet bien conduit;  la programmation représentant 15 à 20% de l'effort de développement d'un logiciel, voire 10% selon certains chiffres; 27  Activités de développement la validation et vérification représentent de l'ordre de 40% de l'effort total d'un projet; Chaque activité utilise et produit des documents. L'importance des activités varie en fonction: du processus de développement choisi; de la nature du logiciel à produire. 28  Le cycle de vie en cascade Le modèle de la cascade prévoit un certain nombre d'étapes ou phases durant lesquelles les activités vont se déroulées Une étape doit se terminer à une date donnée par la production de certains documents ou logiciels. Les résultats de l'étape sont soumis à une revue approfondie. L'étape suivante n'est abordée que s'il sont jugés satisfaisants. 29  Le cycle de vie en cascade Etude de faisabilité + Analyse des besoins Cahier des Analyse charges + Gestion Conception de projet + Spécifications Réalisation Gestion + + du changement Dossiers de Vérification Conception + (Générale et détaillée) Gestion de Code Intégration l’environnement + + Tests unitaires Validation Exploitation Produit + + Doc utilisateur Maintenance 30  Le cycle de vie en cascade Avantages :  Définition des tâches à accomplir  Détermination des livrables à fournir  Séparation des problématiques (métier / technique) Inconvénients :  Obligation de définir la totalité des besoins au départ  Validation fonctionnelle tardive  Code disponible tardivement dans le projet  Projets rarement séquentiels  Aucune préparation des phases de vérification 31  Le cycle de vie en cascade  Les versions actuelles de ce modèle font apparaître la validation vérification à chaque étape.  faisabilité et analyse des besoins + validation  conception du produit, conception détaillée + vérification  codage + test unitaire  intégration + test d'intégration + test d'acceptation  installation + test du système  Il existe de nombreux documents, normes ou recommandations décrivant très précisément le modèle de la cascade: IEEE, AFNOR 32  Le cycle de vie en V On retrouve les caractéristiques du cycle en cascade – Phases successives – Une activité principale et des livrables par phase – Des activités transverses – Remise en cause de la phase précédente Chaque phase en amont de la production du logiciel prépare la phase correspondante de vérification en aval de la production du logiciel 33  Le cycle de vie en V Le principe de ce modèle en V, est qu'avec toute décomposition doit être décrite la recomposition et que toute description d'un composant est accompagnée de ses tests (correspondance avec sa spécification) permettant sa vérification et validation. Le modèle en V rend explicite le fait que les premières étapes préparent les dernières faisant intervenir, essentiellement, vérification et validation. 34  Le cycle de vie en V  Ce principe évite un écueil bien connu de la spécification de logiciel: on énonce une propriété qu'il est impossible de vérifier objectivement, une fois le logiciel réalisé. De plus, l'obligation de concevoir les jeux de test et leurs résultats oblige à une réflexion et ainsi à des retours sur les descriptions en cours. Ainsi les étapes de la branche droite du V peuvent être mieux préparées et planifiées.  Les dépendances entre étapes sont de types: – enchaînement et itération éventuelle du modèle de la cascade en suivant le V (haut-bas, gauche-droite); – une partie des résultats de l'étape de départ sont directement utilisés par celle d'arrivée. 35  Le cycle de vie en V Etude de faisabilité Exploitation + + Analyse des besoins Maintenance Cahier de recettes Analyse Validation Cahier des charges Dossier d’intégrati on Conception Intégration Spécifi- cations Réalisation Dossiers de Code Conception + (Générale et détaillée) Tests unitaires Gestion de projet + Gestion du changement + Gestion de l’environnement 36  Le cycle de vie en V Avantages : Préparation des phases de vérification au moment de l’Analyse et de la Conception Inconvénients : Obligation de définir la totalité des besoins au départ Validation fonctionnelle tardive Code disponible tardivement dans le projet Projets rarement séquentiels 37  Le cycle de vie en Y  Cette démarche itérative (à tout point de vue) distingue l’étude des aspects globaux du SI de l’entreprise de ceux spécifiques à chaque application.  La démarche préconise deux activités d’ingénierie transverses : – l’analyse métier qui correspond à l’étude fonctionnelle – l’architecture technique, qui correspond à l’étude technique.  Ces deux activités enrichissent respectivement un référentiel des processus métier de l’entreprise tenant compte de l’urbanisme du SI et un référentiel de solutions techniques. 38  Le cycle de vie en Y Cahier des Cahier des charges charges Analyse métier Conception Spécifi- Dossiers cations de Gestion Simulation Prototypage Conceptio de projet des n + spécifications Mécanismes + Gestion Design du Codage Patterns changement + Code +Tests Gestion unitaires de l’environ- Sources + nement Objets Exploitation + Librairie s Maintenance Réutilisation Composants métier 39  Le cycle de vie en Y Avantages :  Utilisation immédiate de toutes les compétences  Meilleure traçabilité sur l’ensemble du développement (réutilisation des modèles d’Analyse + règles de passage)  Validation précoce des besoins  Possibilité de générer le code automatiquement  Industrialisation de la réutilisation Inconvénients :  Obligation de définir la totalité des besoins au départ 40  Le cycle de vie en spirale  Inventé par Boehm (Cocomo) en 1988  Le projet est découpé en N phases successives suivies d’une dernière phase où le logiciel est intégralement développé  Chaque phase a pour objectif la validation d’un point technique ou fonctionnel particulier pouvant donner lieu au développement d’une maquette  Chaque phase peut donner lieu à l’utilisation d’un cycle en V ou en Y  Chaque phase permet d’affiner les besoins de l’utilisateur  A chaque phase est associée une analyse de risques pouvant remettre en cause le développement 41  Le cycle de vie en spirale Chaque cycle est décomposé en 4 étapes: 1. détermination des objectifs, des alternatives, des contraintes à partir des résultats du cycle précédent et pour le premier à partir d'une analyse préliminaire des besoins; 2. analyse des risques, évaluation des alternatives, éventuellement prototypage; 3. développement et vérification de la solution retenue (modèle de la cascade ou en V); 4. revue des résultats et planification du cycle suivant. 42  Le cycle de vie en spirale Tests Développement Déploiement Conception Définition des besoins Analyse 43  Le cycle de vie en spirale Avantages :  Mise en œuvre d’une analyse de risques  Les besoins sont affinés au fur et à mesure  Validation fonctionnelle et technique précoces  Il est plus particulièrement adapté aux projets innovants, à risques et dont les enjeux sont importants.  Un des intérêts du modèle en spirale est de fournir la liste des risques majeurs encourus dans le cadre du développement d'un système informatique. Inconvénients :  Le cycle N ne s ’appuie pas obligatoirement sur le cycle N-1  Chaque cycle produit un composant du système intégré en phase finale  Les maquettes développées à chaque cycle ne sont pas obligatoirement réutilisables  Risque de « spiralisation » des besoins  Nécessite une plus grande participation de la part des utilisateurs 44  Le cycle de vie itératif et incrémental  Le projet est découpé en N itérations successives  Chaque itération étend un noyau logiciel antérieurement développé lors des itérations précédentes  Chaque phase peut donner lieu à l’utilisation d’un cycle en V ou en Y  Chaque itération permet d’affiner les besoins de l’utilisateur  A chaque itération est associée une analyse de risques pouvant remettre en cause le développement 45  Le développement incrémental  Rendre les objets de plus en plus précis – accepter une définition floue au départ – affiner par étapes successives  Les impacts d’un incrément doivent être maîtrisés : – nécessité d’une gestion de configuration – nécessité d’une gestion des changements 46  Le processus itératif temps passé Itération 1 Itération 2 Itération 3 Itération 4 Prototype fonctionn el Capture des besoins Analyse Conception Codage temps passé Prototyp Itération 2 Itération 3 Itération 1 Itération 4 e techniqu e Capture des besoins Analyse Conception Codage 47  Modèle par incréments Dans les modèles spirale, en V ou en cascade, il implicite que qu'après une décomposition en composants, ceux-ci sont développés indépendamment les uns des autres, en parallèle ou séquence selon les ressources disponibles. Dans le modèle par incréments, seul un sous ensemble est développé à la fois. Dans un premier temps un logiciel noyau est développé, puis successivement, les incréments sont développés et intégrés. 48  Modèle par incréments  Les avantages d'une telle pratique sont nombreux: chaque développement est moins complexe; les intégrations sont progressives; il peut y avoir des livraisons et mises en oeuvre après chaque incrément; l'effort est constant dans le temps par opposition au pic pour spécifications détaillées pour les modèles en cascade ou en V.  Les inconvénients sont: la remise en cause du noyau de départ; celle des incréments précédents; ou encore l'impossibilité d'intégrer un nouvel incrément. 49  Modèle par incréments  Figure 4: Modèle par incréments 50  Modèle par incréments Afin de réduire ces risques, il est nécessaire de définir les incréments au début du projet et ce de façon globale. D'autre part, les incréments devront être le plus indépendant possible, aussi bien fonctionnellement qu'au niveau de la séquence de développement. 51  Problèmes  Imaginer des solutions méthodologiques qui permettent – de développer et de faire évoluer un logiciel suivant les besoins réels des utilisateurs – d'impliquer davantage les utilisateurs et les responsables à tous les niveaux de management dans le processus de décision et de développement des logiciels – de réduire le fardeau de la maintenance et le coût de développement Définir des méthodologie pour le développement du logiciel 52  METHODOLOGIES Ensemble des méthodes et des techniques d'un domaine particulier Manière de faire, procédé, méthode Ensemble structuré et cohérent de méthodes, guides et outils permettant de déduire la manière de résoudre un problème 53  Méthode (1)  « Processus discipliné qui génère un ensemble de modèles décrivant les différents aspects d'un système logiciel, en utilisant une certaine notation bien définie » (Booch, 94)  Ensemble de règles bien définies qui conduisent pour un problème à une solution correcte  Une méthode a pour objet – de décrire l'ensemble des tâches à accomplir, – l'ordonnancement de ces tâches, – les documents et les standards qui leur sont associées, – afin de prendre en charge des aspects spécifiques ou une partie du processus de développement 54  Méthode (2)  Une méthode : – définit la documentation à fournir à l'issue de chaque phase de développement – spécifie en détail les activités permettant d'atteindre un objectif donné – Les méthodes de développement utilisées sont nombreuses et variées – Elles peuvent recouvrir tout ou partie du cycle de vie et sont axées sur une ou plusieurs approches de développement du SI  Les quatre composantes d'une méthode : – Modèles – Langages – Démarche – Outils 55 Méthode = Démarche + Formalisme  Démarche : succession d’étapes pour – Mieux maîtriser le déroulement d’un projet – Meilleure visibilité pour les utilisateurs sur certains résultats intermédiaires et garantir que le résultat final sera celui attendu  Formalisme défini par: – Un langage formel – Un langage semi-formel généralement graphique – Un langage naturel  Fonction : – Représenter le monde réel tel qu’il est perçu par le concepteur – Outil de communication entre informaticiens et utilisateurs  Constitué par un ensemble de modèles permettant d’assurer une bonne compréhension des besoins des utilisateurs 56  Merise  Merise : Méthode d’Études et de Réalisation Informatique des Systèmes Évolués (1979)  80% du marché français  Trois phases: analyse (diagnostic), conceptualisation (modélisation) et développement (Bases de données)  Modèles: – MCC: Modèle Conceptuel de Communication – MCD: Modèle Conceptuel de Données – MCT: Modèle Conceptuel de Traitements – MOT: Modèle Organisationnel de Traitements – MLD: Modèle Logique de données – MPD: Modèle Physique de données 57 L'expression des besoins est une étape consistant à définir ce que l'on attend du système d'information automatisé, il faut pour cela: faire l'inventaire des éléments nécessaires au système d'information délimiter le système en s'informant auprès des futurs utilisateurs Cela va permettre de créer le MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre compte L'étape suivante consiste à mettre au point le MCD (Modèle conceptuel des données) et le MCT (Modèle conceptuel des traitements) décrivant les règles et les contraintes à prendre en compte Le modèle organisationnel consiste à définir le MOT (Modèle organisationnel des traitements) décrivant les contraintes dûs à l'environnement (organisationnel, spatial et temporel) Le modèle logique représente un choix logiciel pour le système d'information Le modèle physique reflète un choix matériel pour le système d'information 58  Niveau conceptuel On ne se préoccupe ni de l ’organisation ni du matériel utilisé  Il s ’agit de répondre à la question QUOI ?  Quoi faire ?  Avec quelles données  Les modèles sont Modèle conceptuel des données Modèle conceptuel des traitements 59  Niveau organisationnel On intègre les critères d ’organisation de travail On tient compte et/ou on propose des choix d ’organisation de travail Il s ’agit de répondre aux questions Qui? Où? Quand?  Le modèle est : – Modèle Organisationnel des Traitements 60  Niveau physique On étudie les solutions techniques Il s ’agit de répondre à la question comment ?  Les modèles étudiés sont :  le modèle logique des données  le modèle physique des données 61  La démarche Quatre étapes Etude préalable Etude détaillée Réalisation Mise en œuvre 62  Etude préalable  Recueil des données grâce à des entretiens  cerner le projet  comprendre les besoins  identifier des concepts ( règles de gestion, règles d ’organisation …)  proposer une première solution  proposer une évaluation quantitative et qualitative  Diagramme de flux  Dossier d ’étude préalable 63  Etude détaillée  Décrire complètement, au plan fonctionnel la solution à réaliser  Débouche sur un dossier de spécifications détaillées 64  Réalisation  Production du code informatique  Débouche sur un dossier de réalisation 65  Le MCC  Souvent connu sous le nom de graphe des flux, c'est un outil très simple qui permet de représenter tous les flux d'information qu'échange le SI avec son environnement  Ce modèle ne manipule que deux concepts : l'acteur et le flux  L'acteur est soit interne au SI soit externe. On peut faire autant de MCC que de domaines étudiés quitte ensuite à les fusionner pour avoir une vision plus synoptique.  Le flux est soit entrant, soit sortant, d'où la flèche pour le symboliser. Il est porteur de messages, d'informations que l'on peut analyser. A ce stade conceptuel nous ne cherchons pas à savoir quel est le support utilisé (voie, téléphone, courrier, fax, EDI etc.). 66  Exemple  Les clients font leurs demandes de livraison au magasin.  Le magasin donne l ’ordre au transporteur d ’effectuer la livraison.  Lorsque celle-ci est faite, le magasin en est averti par un bon de livraison.  Il envoie alors l ’ordre de facturer au service facturation.  Celui-ci émet une facture pour le client et un double est envoyé à la caisse.  La caisse reçoit les chèques des clients et les dépose à la banque. 67 Recherche des acteurs et des flux  Acteurs externes :  client,  transporteur,  caisse  banque  Acteurs internes :  facturation,  magasin  flux :  demande de livraison, ordre de livraison, bon de livraison,  ordre de facturation, facture,  chèque,  chèque à encaissement 68  Règles de gestion Associées au niveau conceptuel, elles répondent à la question « QUOI ? ». Elles décrivent les actions qui doivent être effectuées et les règles associées à chacune de ses actions. Les règles de gestion représenteront les objectifs choisis par l’entreprise et les contraintes associées. 69  Exemple : règles de gestion  Un inventaire des stocks doit être dressé chaque mois.  Une commande non livrable sera mise en attente. 70  Règles d ’organisation Elles sont associées au niveau organisationnel et décrivent le où, qui et quand. Elles traduisent l’organisation mise en place au sein de l’entreprise afin d’atteindre les objectifs. 71  Exemple : Règles d ’organisation c ’est la secrétaire qui édite les factures chaque fin de semaine. 72  Le MCD Schéma qui obéit à quelques conventions graphique très simples et à quelques règles de construction, peu nombreuses mais très précises qui font la puissance et la pertinence de cet outil Il manipule essentiellement deux concepts : les ENTITES et les ASSOCIATIONS. 73  Le modèle Conceptuel des données Représentation graphique des données et des liens qui existent entre chacune d ’elle. Les concepts de base :  Entités  Propriétés  Relations  Cardinalités  Identifiants 74 Le modèle Conceptuel des données Entité Définition –pourvue d ’une existence propre –conforme aux choix de gestion de l ’entreprise Elle peut être : –un acteur : client, fournisseur –un flux : livraison, commande 75  Les entités Assuré num nom Prenom adresse age Elles représentent soit une personne physique, soit une personne morale soit une chose, soit des événements Une entité forme un tout qui regroupe des occurrences de même nature. Toutes les occurrences d'une entité sont décrites par un ensemble de propriétés dont les valeurs changent d'une occurrence à l'autre. Elle est représentée tout simplement par un rectangle muni d'une cartouche qui indique son nom et elle contient la liste de toutes ses propriétés. 76 Le modèle Conceptuel des données Propriétés Définition : Donnée élémentaire qui qualifie l ’entité à laquelle elle se rapporte Caractéristiques : – occurrence : valeur que peut prendre la propriété – domaine de définition : ensemble des valeurs possibles de la propriété Une propriété peut être composée c'est à dire qu'elle renferme d'autres propriétés plus élémentaires (identité, adresse complète, contact). Toutes les propriétés ont un nom, et un même nom ne doit pas faire référence à deux propriétés distinctes. 77 Le modèle Conceptuel des données Identifiant Définition : Propriété ( ou ensemble de propriétés ) particulière qui permet d ’identifier de façon unique une occurrence de l ’entité. Pour être identifiant, la ou le groupe de propriétés ne peut pas prendre plusieurs fois la même valeur sur l ’ensemble des occurrences possibles de l ’entité. Identifiant d ’une relation : Concaténation des identifiants des entités participant à la relation. 78 Le modèle Conceptuel des données Identifiant  Parmi les propriétés une (ou une combinaison de 2 ou 3) joue un rôle particulier car elle permet d'identifier à coup sur une occurrence : c'est l'identifiant. Le plus souvent c'est un numéro, un code, une référence etc.  Soit il existe déjà dans la réalité du SI et s'impose car il est exogène, soit plus fréquemment il est le fruit d'une codification interne au système qui obéit à un plan de codification plus ou moins élaboré (le N° de prof, d'étudiant dans la promo, le code type de stage etc.).  Toute entité doit avoir un identifiant, en principe celui-ci est stable, c'est à dire que sa valeur pour une occurrence donnée ne change pas. Par construction il apparaît en tête des propriétés et il est souligné. 79 Le modèle Conceptuel des données Associations Définition : Lien sémantique reliant un ensemble d ’entités et présentant un intérêt pour l ’entreprise Association porteuse : Relation qui porte des propriétés. Dimension d ’une association : Association binaire :lien entre deux entités Association ternaire : lien entre trois entités Association n-aire : lien entre n entités Association réflexive : lien de l ’entité sur elle-même 80  Les associations  Ce sont elles qui mettent en relation les entités et donne à l'ensemble la caractéristique de système. Chaque fois que possible il est bon de les nommer par un verbe à l'infinitif car il y a toujours plusieurs sens de lecture.  La plupart des associations sont binaires, c'est à dire qu'elles relient deux entités. Par exemple Effectuer associe étudiant et stage : un stage est effectué par un étudiant et ce dernier peut effectuer plusieurs stages : les deux sens de lecture sont chacun porteur de sens.  Pour être plus précis encore MERISE introduit les notions de cardinalités minimales et les cardinalités maximales. Chaque sens de lecture sera entièrement décrit lorsqu'on aura précisé le couple (cardinalité mini, cardinalité maxi). 81 num Association Règles de gestion: -Un assuré peut posséder 0 ou n véhicules -Un véhicule peut être assuré par un et un seul assuré 82 Le modèle Conceptuel des données Cardinalités Définition : Quantifient le nombre d ’occurrences d ’une entité qui participent à une occurrence cardinalité minimale :combien d ’occurrence au minimum? (0 ou 1) cardinalité maximale :combien d ’occurrence au maximum ? ( 1 ou n ) 83  Les cardinalités  (1,1)  (0,n)  (1,n)  (0,1)  Lorsque la cardinalité maximale d'un des deux sens de lecture vaut 1 on dit alors que l'association binaire est fonctionnelle. Elle s'appelle aussi une dépendance fonctionnelle (DF) ou contrainte d'intégrité fonctionnelle (CIF)  Lorsque les deux cardinalités maximales sont n l'association binaire est non fonctionnelle 84  Démarche dans la construction d ’un MCD – Recherche des propriétés à gérer (Dictionnaire de données) – Lister les Dépendances Fonctionnelles (DF) – Tracer le Graphe de Dépendances Fonctionnelles (GDF) – Regroupement des propriétés par entité – Représentation des entités – Recherche des relations – Recherche des cardinalités – Vérification validation du modèle 85 CONSTRUCTION DU MCD Recherche des propriétés à gérer – Par l ’intermédiaire d ’interview – Par le diagramme acteur/flux – Une donnée est caractérisée par :  Un nom  Une définition  Un domaine de définition  Une provenance  Un mode de calcul ( si donnée calculée )  Une décomposition ( si donnée non atomique ) 86 CONSTRUCTION DU MCD Dictionnaire de données – Recense toutes les informations utiles au système considéré. – Formalisé par un tableau : Nom abrégé, Description, Type, Nature, Commentaires 87 CONSTRUCTION DU MCD Représentation des entités – Première ébauche du modèle conceptuel des données ne faisant apparaître que : entités propriétés 88 CONSTRUCTION DU MCD Recherche des associations – Ecrire des phrases « en français » décrivant le modèle : permet d ’établir des liens entre les entités. – Caractéristiques : Nom collection cardinalité 89 CONSTRUCTION DU MCD Recherche des cardinalités Répondre à quatre questions : Une occurrence de A peut être en relation avec une occurrence de B combien de fois au minimum ? combien de fois au maximum? Une occurrence de B peut être en relation avec une occurrence de A combien de fois au minimum ? combien de fois au maximum? 90 CONSTRUCTION DU MCD Règles de normalisation – Qu ’est ce que les règles de normalisation ? Cinq formes normales Définies par des contraintes de dépendances – But Rendre le modèle le « plus propre possible », Limiter la redondance de données 91  Dépendances fonctionnelles  Dans de nombreuses bases de données, le contrôle de la redondance et la préservation de la cohérence des données sont les plus importants auxquels est confronté le concepteur et l’administrateur.  La redondance survient quand une information est stockée dans plusieurs endroits. Si ce contenu est modifié, il faut le modifier au niveau de chacune des copies. Si certaines, mais pas toutes les copies, sont modifiées les données sont incohérentes.  Pour éviter ses écueils, cela passe par l’étude des dépendances fonctionnelles. 92 Dépendances fonctionnelles Définition : Une dépendance fonctionnelle, notée DF, indique que la valeur d'un ou plusieurs attributs est associée à au plus une valeur d'un ou plusieurs autres attributs. 93  Dépendances fonctionnelles (DF)  X et Y deux ( ou plusieurs) attributs de la B.D.  X  Y : Y dépend fonctionnellement de X  La connaissance de la valeur de X entraîne la connaissance de la valeur de Y.  X détermine Y.  Pour une valeur de X, il existe une et une seule valeur de Y.  Si un attribut (ou un groupe d'attributs) détermine par DF tous les autres attributs de la même relation, c'est une clé de la relation.  Exemple : – Id_article  désignation – (Numcom, NumLigne)  Idarticle – CNENomEtud, PrenomEtud – IdMatiereNomMatiere 94 Dépendances fonctionnelles  Les contraintes se classent en deux groupes – Les contraintes sémantiques : dépendent de la signification ou de la compréhension des attributs d’une relation Dans une relation Personnel(Nom, Age, Salaire) aucun âge ou salaire ne peut être négatif – Les contraintes d’accord ou de concordance ne dépendent pas des valeurs particulières d’un attribut d’un tulpe mais du fait que les tulpes qui acceptent certains attributs acceptent ou non les valeurs de certains de leurs autres attributs Dans une relation Personnel (employé, âge, salaire, service, chef de service) si un employé ne travaille que dans un service et que chaque service n’a qu’un chef de service alors deux tulpes ayant la même valeur dans la colonne chef de service on doit avoir la même valeur dans service. On a une dépendance fonctionnelles  Les dépendances fonctionnelles sont les plus importante contraintes de concordance ou d’agrément. 95  Dépendances fonctionnelles  Définition d’une dépendance fonctionnelle élémentaire – une DF, X  B, est une dépendance fonctionnelle élémentaire si B est un attribut unique, et si X est un ensemble minimum d'attributs (ou un attribut unique).  Exemples : Dans la relation Produit, les DF : – NP  (couleur, poids) et (NP, NomP)  Poids ne sont pas élémentaires.  Mais les DF : – NP  Couleur, NP  Poids, NP  NomP – NomP  Couleur, NomP  Poids, NomP  NP sont élémentaires.  La DF : – (NP, NF, date)  Qté de la relation Livraison est élémentaire. 96  Dépendances fonctionnelles  Soient W, X, Y et Z des ensembles d'attributs non vides d'une relation R. Voici quelques propriétés remarquables:  Réflexivité – W est une partie de X alors (X  W)  Augmentation – (W  X) (W, Y  X, Y)  Transitivité – (W  X et X  Y) (W  Y)  Union – (W  X et W  Y) (W  X, Y)  Pseudo-transitivité – (W  X et X, Y  Z) (W, Y  Z)  Décomposition – (W  X et Y une partie de X) (W  Y) 97  Première forme normale  Une relation est en première forme normale si : – Elle possède une clé – Tous ses attributs sont atomiques : c'est à dire n'ayant à un instant donné qu'une seule valeur ou ne regroupant pas un ensemble de valeurs. – Ses éléments sont indivisibles ( une seule valeur).  Si les tables relationnelles résultant de la modélisation ne sont pas déjà en 1FN, il serait approprié de retourner à l’étape de modélisation.  Une modélisation de qualité minimale devrait toujours être en 1FN. Un schéma R est en 1NF Si et seulement si les domaines de tous ses attributs sont 98  Première forme normale Exemple : Clientèle = (IdClient, nom, adresse, tel) Adresse comporte 2 valeurs : adresse et ville, d’où : Clientèle = (IdClient, nom, adresse, ville, tel ) est en 1NF 99  Deuxième forme normale Une relation est en deuxième FN si : – Elle est en 1FN – Toutes les DF sont élémentaires par rapport à la clé : tout attribut hors clé ne dépend pas d’une partie de la clé Un schéma R est en 2FN Si et seulement si Tout attribut de R, n’appartenant pas à la clé primaire , est en dépendance fonctionnelle totale de la clé primaire 100  Deuxième forme normale Exemple – Patient (N°patient, Date consultation, Nom) – Nom dépend d’une partie de la clé N°patientNom – Le 2NF permet d’éliminer certaines redondances Patient (N°patient,Nom) Consultation (N°patient*,Date consultation, ordonnance) Mais il peut rester des redondances … 101  Troisième forme normale Une relation est en troisième forme normale si : – Elle est en 2 FN – Tout attribut hors clé est en DF directe par rapport à la clé (pas de transitivité) Un schéma R est en 3NF ssi R est en 2NF, Aucun attribut ne dépend transitivement de la clé primaire, (tout attribut de R, n’appartenant pas à la clé, ne 102  Troisième forme normale  La 3NF permet d’éliminer des redondances, dues à des dépendances transitives entre attributs mais elle ne suffit pas parfois à éliminer toutes les redondances : – Codepostal (Code, Ville, Rue) – Les DF sont Code Ville et Ville,Rue  Code – Cette relation est en 3NF puisque aucun attribut non clé ne dépend d’une partie de la clé ou d’un attribut non clé mais il y a des redondances : Code Ville Rue 54505 Vandoeuvre Aiguillette 54505 Vandoeuvre Gal Leclerc 103  Forme de Boyce-Codd (BCNF)  Une relation est en BCNF si : – Elle est en 3 FN – Tout attribut non clé de la relation n'est pas source de DF vers une partie de la clé.  Ou – Les seules DF élémentaires qu’elle comporte sont celle où une clé détermine un attribut.  Dans l’exemple précédant : CodeVille (Code*, Ville) CodeRue (Code, Rue) Sont en BCNF, mais perte de la DF Ville,Rue ->Code  Toute relation a une décomposition en BCNF sans perte d’information, par contre, une décomposition en BCNF ne préserve pas généralement les DF. 104 Forme de Boyce-Codd (BCNF) 105  Méthode de normalisation  Il est souhaitable qu’un schéma relationnel ne comporte que des relations en 3NF ou BCNF.  Des algorithmes de constructions permettent d’obtenir de tels schémas. Ils sont de deux catégories : – La méthode de décomposition : Elle se base sur la décomposition de relations en utilisant les DF entre les données. Cette méthode conduit à des relations en 3NF ou BCNF. Il y a 2 problèmes : – Identification des DF et leurs exhaustivité – Le résultat dépend de l’ordre d’application des décompositions et peut ne pas préserver les DF – La méthode synthétique Elle se base sur la représentation des DF en terme de graphes (graphe et leur couverture) 106  Méthode synthétique  Point de départ – L’ensemble de tous les attributs – L’ensemble des DF entre attributs qui sont représentées dans un graphe avec comme nœud un attribut et comme arc une DF  Ce qu’il faut faire – Trouver la couverture minimale du graphe c’est-à-dire éliminer les circuits ainsi que les DF non élémentaires et non directes  Résultat – Une collection de relation en 3NF. Chaque schéma est obtenu en prenant comme : Clé une source de DF Attributs, les buts des DF correspondant 107  Exemple  Service d’immatriculation de voitures dans une préfecture – Soient les DF suivantes : N°Immat -> Couleur, Type, Puissance, Marque N°Pers -> Nom, Prénom, Adresse N°Immat -> N°Pers et Type -> Marque, Puissance – On crée le graphe : N°Pers N°Immat Type Puissance Nom Prénom Adresse Couleur On supprime les transitivités Marque On obtient : Personne (N°Pers, Nom, Prénom, Adresse) Voiture (N°Immat, Couleur, Type*, N°Pers*) Types (Type, Puissance, Marque) 108