Merise Cours Emsi (Sayouti) [PDF]

Zitiervorschau

---

Conception des systèmes d’information Plan : 1. Introduction  Génie logiciel  Pourquoi Analyser, Concevoir et Modéliser?  Cycle de vie d’un logiciel  Système d’information dans l’entreprise  Méthode MERISE 2. Niveau conceptuel  Modèle Conceptuel de données (MCD)  Modèle Conceptuel de Communication (MCC)  Modèle Conceptuel de traitement (MCT) 3. Niveau logique  Modèle logique de données (MLD) 4. Niveau organisationnel  Modèle Organisationnel de Données (MOD)  Modèle Organisationnel de Traitement (MOT) 5. Niveau physique  Modèle Physique des Données (MPD) 6. Introduction à l’UML

Professeur. Adil SAYOUTI

Introduction - Objectif o Ce Cours a pour objectif de permettre à l’ingénieur de concevoir et modéliser un système d'information. o

Il vise aussi à ce que l’ingénieur soit capable de lire et analyser un cahier des charges en vue de créer un dossier de spécification pour le projet à réaliser ou l’application à développer.

o Analyse : processus d'examen de l'existant. o Analyse des besoins : LE QUOI? o Conception : processus de définition de la future application informatique : LE COMMENT? o Modèle : représentation schématique de la réalité. o Systèmes d'Information : ensemble des moyens (humains et matériels) et des méthodes se rapportant au traitement de l'information d'une organisation. 2

Introduction - Génie logiciel

o Définition : Ensemble de méthodes, techniques et outils dédiés à la conception, au développement et à la maintenance des systèmes informatiques. o Système : ensemble d'éléments en interaction dynamique, dont les éléments sont organisés et coordonnés en vue d'atteindre un objectif, qui évolue dans un environnement. o Système informatique : Un ensemble d’éléments qui sont organisés pour accomplir un but prédéfini par un traitement de l’information. Il Utilise des : logiciels, matériels, personnes, bases de données, documentation, procédures (étapes qui définissent comment utiliser les éléments du système). 3

Introduction - Génie logiciel L'objectif du génie logiciel est d'optimiser le coût de développement du logiciel. L'importance d'une approche méthodologique s'est imposée à la suite de la crise de l'industrie du logiciel à la fin des années 1970. Cette crise de l'industrie du logiciel était principalement due à : • • • • •

l'augmentation des coûts ; les difficultés de maintenance et d'évolution ; la non-fiabilité ; le non-respect des spécifications ; le non-respect des délais.

Remarque : Echéance : Atteindre la fin d'un délai qui avait été prévu pour la réalisation d’une application ou projet.

4

Introduction - Génie logiciel Pour apporter une réponse à tous ces problèmes, le génie logiciel s'intéresse particulièrement à la manière dont le code source d'un logiciel est spécifié puis produit. Ainsi, le génie logiciel touche au cycle de vie des logiciels : o Étude de faisabilité o Analyse des besoins : o Besoins fonctionnels, o Besoins non fonctionnels, o Conception, o Développement (Codage), o Tests unitaires o Intégration et tests o Livraison o Maintenance 5

Introduction -Etude de faisabilité

Étude de faisabilité o Faisabilité économique o Faisabilité technique – Risques de développement – Disponibilité des ressources – Technologie nécessaire o Faisabilité légale o Étude de faisabilité : aspects économiques Analyse du rapport Coût/Bénéfice : – Coût du système – Bénéfices mesurables (en DH ) – Bénéfices non mesurables • meilleure conception • meilleures décisions marketing • satisfaction accrue du client L’analyse Coût/Bénéfice est souvent le moyen d’obtenir le feu vert de la direction.

6

Introduction - Analyse des besoins

Analyse des besoins o Définition des besoins à différents niveaux d’abstraction : – Besoins de l’utilisateur – Besoins des composants o Définition du système à réaliser avec le point de vue de l’utilisateur et/ou du client o Analyse des besoins : LE QUOI o Conception : LE COMMENT

Le processus d’analyse Processus de découverte, de raffinement, de modélisation et de spécification • Les utilisateurs/clients et les développeurs ont des rôles actifs • Les utilisateurs ne sont pas satisfaits par un système bien conçu et bien implémenté Les utilisateurs veulent des systèmes qui satisfont leurs besoins

7

Introduction - Analyse des besoins

o Fournir le livrable qui correspond à la commande passe par une bonne compréhension de la demande client et de son environnement technique.

o Pour cela, le chef de projet logiciel doit s'approprier le contexte, les objectifs, les enjeux et les contraintes du système d'information, recueillir et reformuler les besoins en développement des différentes parties prenantes. Sa force sera de proposer et de mettre en place la solution en adéquation avec les besoins identifiés.

8

Introduction - Analyse des besoins o les parties prenantes de l’entreprise regroupent l’ensemble de ceux qui participent à sa vie économique (salariés, clients, fournisseurs, actionnaires), de ceux qui observent l’entreprise (syndicats, ONG), et de ceux qu’elle influence plus ou moins directement (société civile, collectivité locale). Les parties prenantes sont toutes les personnes ayant un intérêt dans les activités de l’entreprise.

9

Introduction - Analyse des besoins o Cette analyse au début du projet informatique permet de préparer tranquillement (calmement) le lancement de celui-ci pour piloter et superviser les étapes d’avancement de l’intégration de la solution informatique.

10

Introduction - Analyse

o Bases de la communication o Ecouter le client o Préparer les réunions – Connaissance du client et des contacts – Lecture des documents disponibles – Penser aux objectifs de la réunion – Penser aux problèmes – Être à l’heure o Compréhension minimale du problème : – Qui est derrière la demande de cette réalisation ? – Qui va utiliser la solution proposée ? – Y-a-t-il des contraintes ? Des problèmes de performance ?

Une bonne analyse • Objectif premier : Maximiser la satisfaction des utilisateurs et des clients

11

Introduction - Analyse Une bonne analyse o Objectif premier : Maximiser la satisfaction des utilisateurs et des clients o En tenant compte de 3 types de besoin – Normaux : besoins explicitement établis – Attendus : implicites, pas exprimés mais nécessaires – Excitants : allant au delà des espérances des clients

Indications à suivre o Comprendre le problème avant de commencer à créer la spécification des besoins – Ne pas résoudre le mauvais problème o Développer des prototypes des interfaces utilisateurs (IHM) – Les interfaces utilisateurs déterminent souvent la qualité… o Noter et tracer l’origine et les raisons d’un besoin o Utiliser des vues multiples sur les besoins – Réduit les risques de rater quelque chose o Classer les besoins par priorité

12

Introduction - Cahier des charges Le cahier des charges o Première étape de l’expression du besoin o Description globale des fonctions d’un nouveau produit ou des extensions à un produit existant • Énoncé du problème à résoudre • Liste des fonctions de base • Caractéristiques techniques • Priorités de réalisation • Facteurs de qualité o Il doit être validé par le client et/ou l’utilisateur o Il est la base du contrat entre clients et développeurs o Le cahier des charges est un document technique, sans considération économique – sauf si on lui adjoint un plan de projet 13

Introduction - La spécification des besoins La spécification des besoins o La spécification des besoins doit décrire sans ambiguïté le logiciel à développer. o Elle est constituée d’un ensemble de documents et de modèles. o Toutes les personnes impliquées dans le projet doivent avoir accès à la spécification des besoins. o L’énoncé d’un besoin exprime un comportement ou une propriété que le système doit respecter. o Chaque énoncé doit traduire la présence d’un comportement très spécifique

14

Introduction - Besoins fonctionnels/non fonctionnels Besoins fonctionnels o Les besoins fonctionnels expriment une action que doit effectuer le système en réponse à une demande (sorties qui sont produites pour un ensemble donné d’entrées) o Exemple : Le système doit produire automatiquement un rapport de synthèse des ventes hebdomadaires.

Besoins non fonctionnels -

Besoin d’utilisabilité Besoins de performance Besoins de disponibilité/fiabilité Besoins de sécurité Besoins matériels Besoins de déploiement 15

Introduction - Besoins fonctionnels/non fonctionnels Besoins non fonctionnels - Besoin d’utilisabilité font référence aux aspects généraux de l’interface utilisateur - Besoins de performance décrivent les performances d’exécution du système, généralement en termes de temps de réponse. - Besoins de disponibilité/fiabilité exigence de disponibilité 24/24, 7/7 sauf période de maintenance - Besoins de sécurité Toute information confidentielle fournie par les clients via l’Internet sera cryptée avec le système XYZ ou par l’algorithme, la méthode….ABC.. - Besoins matériels définissent les configurations matérielles minimales nécessaires au fonctionnement du système - Besoins de déploiement décrivent la façon dont l’application sera livrée à l’utilisateur final 16

Introduction - Qualité du logiciel En génie logiciel, divers travaux ont mené à la définition de la qualité du logiciel en termes de facteurs, qui dépendent, entre autres, du domaine de l'application et des outils utilisés. Parmi ces derniers, nous pouvons citer : • Validité : aptitude d'un produit logiciel à remplir exactement ses fonctions, définies par le cahier des charges et les spécifications. • Fiabilité ou robustesse : aptitude d'un produit logiciel à fonctionner dans des conditions anormales. • Extensibilité : facilité avec laquelle un logiciel se prête à sa maintenance, c'est-àdire à une modification ou à une extension des fonctions qui lui sont demandées. 17

Introduction - Qualité du logiciel • Réutilisabilité : aptitude d'un logiciel à être réutilisé, en tout ou en partie, dans de nouvelles applications. • Compatibilité : facilité avec laquelle un logiciel peut être combiné avec d'autres logiciels. • Efficacité : Utilisation optimale des ressources matérielles. • Portabilité : facilité avec laquelle un logiciel peut être transféré sous différents environnements matériels et logiciels. • Vérifiabilité : facilité de préparation des procédures de test. 18

Introduction - Qualité du logiciel • Intégrité : aptitude d'un logiciel à protéger son code et ses données contre des accès non autorisés. • Facilité d'emploi : facilité d'apprentissage, d'utilisation, de préparation des données, d'interprétation des erreurs et de rattrapage en cas d'erreur d'utilisation.

.

19

Introduction - Pourquoi modéliser? • Un modèle est une représentation abstraite et simplifiée, d'une entité du monde réel en vue de le décrire, de l'expliquer ou de le prévoir. • Un modèle permet de réduire la complexité d'un phénomène en éliminant les détails qui n'influencent pas son comportement de manière significative. Il reflète ce que le concepteur croit important pour la compréhension et la prédiction du phénomène modélisé. Exemples de modèles : • Modèle météorologique, modèle économique, modèle démographique Modèles prédictifs • Plans (exemple : la construction d'un immeuble) Modèles conceptuels 20

Introduction - Pourquoi modéliser? • Modéliser un système avant sa réalisation permet de mieux comprendre le fonctionnement du système. C'est également un bon moyen pour maîtriser sa complexité et d'assurer sa cohérence. • Un modèle est un langage commun, précis, qui est connu par tous les membres de l'équipe et il est donc, un bon moyen pour communiquer. Cette communication est essentielle pour aboutir à une compréhension commune d'un problème donné. • Dans le domaine de l'ingénierie du logiciel, le modèle permet de mieux répartir les tâches et d'automatiser certaines d'entre elles. C'est également un facteur de réduction des coûts et des délais. • Par exemple, les plateformes de modélisation savent maintenant exploiter les modèles pour faire de la génération de code (au moins au niveau du squelette) 21

Introduction - Pourquoi modéliser? • Le modèle est indispensable pour assurer un bon niveau de qualité et une bonne maintenance. En effet, une fois mise en production, l'application va devoir être maintenue, probablement par une autre équipe, pas nécessairement la même que celle ayant créé l'application. • Le choix du modèle a donc une influence capitale sur les solutions obtenues. Les systèmes non triviaux (ne sont pas simples) sont mieux modélisés par un ensemble de modèles indépendants. Selon les modèles employés, la démarche de modélisation n'est pas la même.

22

Introduction - Cycle de vie d’un logiciel •

Le cycle de vie d'un logiciel, désigne toutes les étapes du développement d'un logiciel, de sa conception à sa mise en production. L'objectif d'un tel découpage est de définir des jalons intermédiaires permettant la validation du développement logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés, et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre. Le jalon est un livrable lié à une date.

•

L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés 23

Introduction - Cycle de vie d’un logiciel Le cycle de vie du logiciel comprend généralement au minimum les étapes suivantes : • Analyse des besoins et faisabilité C'est-à-dire l'expression, le recueil et la formalisation des besoins du demandeur (le client) et de l'ensemble des contraintes, puis l'estimation de la faisabilité de ces besoins ; • Spécifications ou conception générale Il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel ; • Conception détaillée Cette étape consiste à définir précisément chaque sous-ensemble du logiciel ; • Codage (Implémentation ou programmation) C'est la traduction dans un langage de programmation des fonctionnalités définies lors de la phase de conception

24

Introduction - Cycle de vie d’un logiciel • Tests unitaires ils permettent de vérifier individuellement que chaque sous-ensemble du logiciel est implémenté conformément aux spécifications ; • Intégration l'objectif est de s'assurer de l'interfaçage des différents éléments (modules) du logiciel. Elle fait l'objet de tests d'intégration consignés dans un document ; • Qualification (ou recette) c'est-à-dire la vérification de la conformité du logiciel aux spécifications initiales ; • Documentation vise à produire les informations nécessaires pour l'utilisation du logiciel et pour des développements ultérieurs (guide utilisateur et guide technique)

25

Introduction - Cycle de vie d’un logiciel • Mise en production c'est le déploiement sur site (emplacement géographique) du logiciel ; • Maintenance elle comprend toutes les actions correctives (maintenance corrective) et évolutives (maintenance évolutive) sur le logiciel.

La séquence et la présence de chacune de ces activités dans le cycle de vie dépendent du choix d'un modèle de cycle de vie entre le client et l'équipe de développement. Le cycle de vie permet de prendre en compte, en plus des aspects techniques, l'organisation et les aspects humains.

26

Introduction - Modèle en cascade •

Dans ce modèle, le principe est très simple : chaque phase se termine à une date précise par la production de certains documents ou logiciels. Les résultats sont définis sur la base des interactions entre étapes, ils sont soumis à une revue approfondie et on ne passe à la phase suivante que s'ils sont jugés satisfaisants.

•

L'inconvénient majeur du modèle de cycle de vie en cascade est que la vérification du bon fonctionnement du système est réalisée trop tardivement : lors de la phase d'intégration, ou pire, lors de la mise en production

27

Introduction - Modèle en cascade •

Avantages – Adapté aux logiciels ou les exigences sont bien connues et non sujettes à modification  Fonctionnalités/attentes utilisateurs  Technologies utilisées

•

•

•

– Fonctionne très bien quand la qualité est plus importante que les coûts/délais Limites – la vérification du bon fonctionnement du logiciel est réalisée trop tardivement – Fort coût de correction des erreurs si elles sont découvertes tardivement – Ne contient pas d’activités d’analyse de risque – Ne gère pas explicitement les changements des spécifications Quand l’utiliser? – Quand les besoins sont connus et stables – Quand la technologie à utiliser est maîtrisée Exemples: • Création d’une nouvelle version d’un produit existant • Portage d’un produit sur une nouvelle plateforme

28

Introduction - Modèle en V

e plus utilisé. • Il s'agit d'un modèle en cascade dans lequel le développement du logiciel et des tests sont effectués de manière synchrone. • Le principe de ce modèle est que toute description d'un composant est accompagnée de tests qui permettront de s'assurer qu'il correspond à sa description. • Ce modèle souffre toujours du problème de la vérification trop tardive du bon fonctionnement du système. 29

Introduction - Modèle en V •

•

•

Avantages – Force la documentation: une phase ne peut se terminer avant qu’un document ne soit validé – Le test est inhérent à chaque phase Les limites – la vérification du bon fonctionnement du logiciel est réalisée trop tardivement : Très couteux si les erreurs sont constatées – Ne marche que si les exigences sont stables et le problème est connu – Ne contient pas des activités d’analyse de risque – Ne gère pas explicitement les changements des spécifications Quand l’utiliser? – Quand le logiciel à développer à de très hautes exigences de qualité – Quand les besoins sont connus à l’avance – Les technologies à utiliser sont connues à l’avance

30

Introduction - Modèle en spirale •

Ce modèle met l'accent sur l'activité d'analyse des risques : chaque cycle de la spirale se déroule en quatre phases : 1.

2. 3. 4. •

Détermination, à partir des résultats des cycles précédents, ou de l'analyse préliminaire des besoins, des objectifs du cycle, des alternatives pour les atteindre; Analyse des risques, évaluation des alternatives et, éventuellement maquettage ; Développement et vérification de la solution retenue, un modèle « classique » (cascade ou en V) peut être utilisé ici ; Revue des résultats et vérification du cycle suivant.

L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de développement classique 31

Introduction - Modèle en spirale

Spécification des contraintes et objectifs

Cycle 2 Cycle 1 2 1 2

1

4

4 Prévision de la phase suivante

Conception et résolution des problèmes

3 3 Développement, vérification 32

Introduction - Modèle en spirale •

•

•

Avantages • Identification des risques, impacts minimaux des risques sur le logiciel • Fonctions critiques développées en premier • Feedback rapide du client • Une évaluation continue du logiciel Les limites • L’évaluation des risques peut prendre beaucoup de temps • Le modèle est très complexe • La spirale peut s’éterniser Quand l’utiliser? • Quand le prototypage est exigé • Quand le risque est considérable • Quand les spécifications ne sont pas stables • Quand le produit implique de la recherche et de l’investigation 33

Introduction - Modèle par incrément o Dans les modèles par incrément, un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents. o Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés globalement, au début du projet. Les incréments doivent être aussi indépendants que possible, fonctionnellement, mais aussi sur le plan du calendrier du développement. o Les premiers incréments peuvent être des maquettes (jetables s’il s’agit juste de comprendre les besoins des utilisateurs) ou des prototypes (réutilisables pour passer au prochain incrément en les complétant et/ou en optimisant leur implantation).

34

Introduction - Modèle par incrément •

Architecture évolutive – Découpage fonctionnel en sous ensemble – Développement des sous-ensembles par incrément – (un incrément= 1 version). La première version constitue le noyau – Les versions suivantes s’appuient sur l’existant et étendent l’architecture

35

Introduction - Modèle par incrément  Architecture stable – La première version fournit une enveloppe complète – Chaque nouvelle version fournit un ou plusieurs sous système en respectant l’architecture

36

Introduction - Modèle par incrément  Avantages

– Une première version du logiciel est fournie rapidement – Les clients peuvent ajouter des exigences à tout moments – Chaque développement est moins complexe et donne un produit fonctionnel – Possibilité de livraisons et de mises en service après chaque incrément – Le client intervient à la fin de chaque incrément, il entre en relation avec le produit très tôt  Limites – Architecture stable: Réalisation trop complexe; difficile de concevoir une architecture stable dès le début – Exige une vision sur le produit fini pour pouvoir le diviser en incréments – Difficulté de définir le nombre d’incréments – Incréments réutilisables inadaptés

37

Introduction - Modèle par incrément  Quand l’utiliser? – Quand la plupart des spécifications sont connus à l’avances et vont être sujettes à de faibles évolutions – Quand on veut rapidement un produit fonctionnel

– Pour des projets de longues durées – Pour des projets impliquant de nouvelles technologies

38

MERISE Système d’Information o La conception d'un système d'information n'est pas évidente car il faut réfléchir à l'ensemble de l'organisation que l'on doit mettre en place. La phase de conception nécessite des méthodes permettant de mettre en place un modèle sur lequel on va s'appuyer. o La modélisation consiste à créer une représentation virtuelle d'une réalité de telle façon à faire ressortir les points auxquels on s'intéresse. Ce type de méthode est appelé analyse. Il existe plusieurs méthodes d'analyse, la méthode la plus utilisée en France étant la méthode MERISE (Méthode d’Etude et de Réalisation Informatique pour les Systèmes d’Entreprise).

o Le but de cette méthode est d'arriver à concevoir un système d'information. La méthode MERISE est basée sur la séparation des données et des traitements à effectuer en plusieurs modèles conceptuels et physiques. La séparation des données et des traitements assure une longue durée de vie au modèle. En effet, l'agencement des données n'a pas à être souvent modifié (révisé), tandis que les traitements le sont plus fréquemment. 39

MERISE Système d’Information o La méthode MERISE date de 1978-1979, et fait suite à une consultation nationale lancée en 1977 par le ministère de l'Industrie dans le but de choisir des sociétés de conseil en informatique afin de définir une méthode de conception de systèmes d'information. Les deux principales sociétés ayant mis au point cette méthode sont le CTI (Centre Technique d'Informatique) chargé de gérer le projet, et le CETE (Centre d'Etudes Techniques de l'Equipement) implanté à Aix-en-provence.

40

MERISE Système d’information dans l’entreprise

o 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 peut plus fonctionner avec une qualité de service satisfaisante. o L’enjeu de toute entreprise industrielle ou de services consiste donc à mettre en place un système destiné à collecter, mémoriser, traiter et distribuer l’information. o Ce système d’information assurera le lien entre deux autres systèmes de l’entreprise : système de pilotage et le système opérant

41

MERISE Système d’information dans l’entreprise o Le système de pilotage décide les actions à exécuter par le système opérant en fonction des objectifs et des politiques de l’entreprise. o 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, …

42

MERISE Système d’information dans l’entreprise

43

MERISE Architecture d’un système d’information o Le système d’information doit décrire (ou représenter) le plus fidèlement possible le fonctionnement du système opérant. Pour ce faire, il doit intégrer une base d’information dans laquelle seront mémorisés la description des objets, des règles et des contraintes du système opérant. Cette base subit des évolutions.

o Le système d’information doit être doté d’un mécanisme (appelé processeur d’information) destiné à piloter et à contrôler ces changements.

44

MERISE Architecture d’un système d’information o Le processeur d’information produit des changements dans la base d’information à la réception d’un message. Un message contient des informations et exprime une commande décrivant l’action à entreprendre dans la base d’information. o L’architecture présentée ci-dessus induit une double conception : • Celle de la base d’information (aspect statique), • Celle du processeur de traitement (aspect dynamique). o Pour aider le concepteur dans ces deux tâches, la méthode Merise propose un ensemble de formalismes et de règles destinées à modéliser de manière indépendante les données et les traitements du système d’information.

45

Présentation de la méthode Merise • Pour la méthode MERISE, la conception des systèmes d’information (SI) est réalisée selon la démarche suivante :

46

Présentation de la méthode Merise o Le schéma directeur : dont le rôle est de définir, de manière globale, la politique d’organisation et d’automatisation du système d’information. Pour ce faire, il est nécessaire de répertorier l’ensemble des applications informatiques existantes à modifier et à développer. o Pour rendre contrôlable et modulable ce développement, il est nécessaire de découper le système d’information en sousensembles homogènes et relativement indépendant. Ces sousensembles sont appelés domaines. Par exemple, on peut trouver le domaine « comptabilité », le domaine « Personnel »... o Les résultats attendus à la fin de cette étape sont une définition précise des domaines, une planification du développement de chaque domaine et un plan détaillé, des applications qui doivent être réalisées. 47

Présentation de la méthode Merise o L’étude préalable (par domaine) : doit aboutir à une présentation générale du futur système de gestion (modèles de données et de traitements) en indiquant les principales novations par rapport au système actuel, les moyens matériels à mettre en œuvre, les bilans coût – avantage. Cette étude est réalisée en quatre phases : • Une phase de recueil : analyser l’existant afin de cerner les dysfonctionnements du système actuel. • Une phase de conception : pour objectif de formaliser et hiérarchiser les orientations nouvelles en fonction des critiques formulées sur le système actuel et d’autre part des politiques et des objectifs de la direction générale. • Une phase d’organisation dont l’objectif est de définir le système futur au niveau organisationnel : qui fait quoi ? • Une phase d’appréciation dont le rôle est d’établir les coûts et les délais des solutions définies ainsi que d’organiser la mise en œuvre de la réalisation. A cet effet un découpage en projets est effectué.

48

Présentation de la méthode Merise o L’étude détaillée (par projet) consiste d’une part à affiner (amèliorer) les solutions conçues lors de l’étude préalable et d’autre part à rédiger, pour chaque procédure à mettre en œuvre, un dossier de spécifications détaillé décrivant les supports ainsi que les algorithmes associés aux règles de gestion… A l’issue de cette étude, il est possible de définir le cahier des charges ainsi que le fonctionnement détaillé du futur système, du point de vue de l’utilisateur. o La réalisation (par application) l’objectif est l’obtention des programmes fonctionnant sur un jeu d’essais approuvés par les utilisateurs. o La mise en œuvre se traduit par un changement de responsabilité: l’équipe de réalisation transfère la responsabilité du produit à l’utilisateur. Cette étape intègre en particulier la formation des utilisateurs. Après une période d’exploitation de quelques mois, la recette définitive de l’application est prononcée. o La maintenance consiste à faire évoluer les applications en fonction des besoins des utilisateurs, de l’environnement et des progrès technologiques.

49

Merise Cycles d’abstraction de conception des SI

La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitement afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données inutiles.

Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information.

50

Merise Cycles d’abstraction de conception des SI

o L'expression des besoins aboutit au MCC (Modèle conceptuel de la communication) qui définit les flux d'informations à prendre en compte. o 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. o Le modèle organisationnel consiste à définir le MLD (Modèle logique des données) qui représente un choix logiciel pour le système d'information et le MOT (Modèle organisationnel des traitements) décrivant les contraintes dues à l'environnement (organisationnel, spatial et temporel). o Le modèle physique reflète un choix matériel pour le système d'information.

51

Merise Cycles d’abstraction de conception des SI La méthode Merise préconise trois niveaux d’abstraction : o Le niveau conceptuel qui décrit la statique et la dynamique du système d’information en se préoccupant uniquement du point de vue du gestionnaire. Niveau Conceptuel : • Ce qu’il faut faire ; • Quoi ? o Le niveau organisationnel (logique) décrit la nature des ressources qui sont utilisées pour supporter la description statique et dynamique du système d’information. Ces ressources peuvent être humaines et/ou matérielles et logicielles. • Niveau organisationnel : - La manière de faire ; - Pour les traitements. • Niveau logique : - Choix des moyens et ressources ; 52 - Pour les données.

Merise Cycles d’abstraction de conception des SI o Le niveau opérationnel dans lequel on choisit les techniques d’implantation du système d’information (données et traitements). • Niveau physique : - Les moyens de le faire ; - Comment ?

53

Présentation de la méthode Merise - Le niveau conceptuel Exprime les choix fondamentaux de gestion. Définit • • •

Des activités Des choix de gestion Des informations

Indépendamment • •

Des aspects organisationnels Des aspects techniques de mise en œuvre

Du point de vue • •

Des traitements: objectif, résultat, règle de gestion, enchaînement Des données: signification, structure, liens

55

Présentation de la méthode Merise - Le niveau organisationnel

Exprime les choix organisationnels de ressources humaines et matérielle Définit: – La répartition géographique et fonctionnelle des sites de travail (du point de vue des données et des traitements) – Le mode de fonctionnement : temps réel ou temps différé. – La répartition du travail homme/machine (degré et type d’automatisation) – Les postes de travail et leur affectation, – La volumétrie des données – La sécurité des données

• Indépendamment des moyens de traitement et de stockage de données actuels ou futurs • Les opérations conceptuelles vont être décomposées au niveau organisationnel en une ou plusieurs opérations organisationnelles

56

Présentation de la méthode Merise - Le niveau logique

• Exprime la forme que doit prendre l’outil informatique pour être adapté à l’utilisateur, à son poste de travail • Indépendamment de l’informatique spécifique, des langages de programmation ou de gestion des données • Décrit – Le schéma de la base de données (relationnel, hiérarchique ou réseau) – La répartition des données sur les déférentes unités de stockage – Les volumes par unité de stockage – L’optimisation des coûts induits par le mode de gestion

57

Présentation de la méthode Merise - Le niveau physique

• Traduit les choix techniques et la prise en compte de leurs spécificité • Répond aux besoins des utilisateurs sur les aspects logiciels et matériels. • Définit complètement: – Les fichiers, les programmes – L’implantation physique des données et des traitements – Les ressources à utiliser, les modalités de fonctionnement

58

Présentation de la méthode Merise - Les modèles

60

Le niveau conceptuel   

Modèle Conceptuel de données (MCD) Modèle Conceptuel de Communication (MCC) Modèle Conceptuel de traitement (MCT)

Modèle conceptuel de données (MCD) La problématique des données • Il ne suffit pas de s’intéresser au nom et aux propriétés des données : type, longueur, valeurs. • Il faut s’intéresser à la donnée elle-même, ses sens et ses usages. • Exemple: sens du mot « client »

Libellé FR

Sens

Client

Correspond à la personne donneur d’ordre

Client de facturation

Désigne la personne destinataire des factures

Client payeur Désigne la personne qui paye les factures

63

Modèle conceptuel de données (MCD) La problématique des données  Il faut aussi se poser des questions sur la qualité des données existantes et les exigences de qualité. Hors nomenclature (pb de conformité et d’intégrité)

Contradiction (pb de cohérence)

n°ss

Nom

Prénom

Date sexe naissance

Adresse

171046734543621 Dupond

Albert

10/04/1971

F

3, rue de la gare

268065415498494 Durant

Lise

18/06/1968

F

Rue des Lilas

268065415498494 Durant

Lisa

18.06.1968

F

Doublon (pb d’unicité)

Erreur de Format (pb de conformité) Absence de valeur Erreur de saisie (pb (pb de complétude) d’exactitude)

Code Postal

Incohérence

Ville

Téléphone

99999 Strasbourg 01 32145678

54000

Nancy

54000

Null

0345762345

0345762345

Pb d’intégrité référentielle

64

Modèle conceptuel de données (MCD)

Objectif du MCD Ecrire de façon formelle les données d’une base de données. Il s'agit donc d'une représentation des données, facilement compréhensible, permettant de décrire la base de données à l'aide d'entités.

 Il est à la base de tous les SGBD dits relationnels (MySQL, SQL Server Oracle, DB2…) qui sont les plus utilisés actuellement dans les entreprises.  Il est généralement représenté à l’aide du formalisme «entitésassociations » sous la forme de : ENTITES, ASOCIATIONS et PROPRIETES. 65

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

Concept concret ou abstrait (un fait, un moment…) identifié du monde réel caractérisé par un nom et une liste de propriétés.  Une entité concrète possède une existence physique : client, équipement, et produit  Une entité abstraite a une existence conceptuelle : une transaction, un tarif, l’annulation d’un vol d’avion

 Exemples  Le client Jean Dupond est une entité concrète  La commande COM0001 est une entité abstraite  L’entité Personne(nom, prénom), et l’entité Voiture(nom , puissance fiscale) ne peuvent pas être groupés en une même entité car ils ne partagent pas leurs propriétés

. Client L’ entité se représente par un cadre contenant le nom de l’entité

66

Modèle conceptuel de données (MCD) Attribut (Entité) Propriété d’une entité ou d’une association caractérisée par un nom et un type élémentaire.

 Est un élément d’une entité : –

a un nom unique,

–

permet de mémoriser une valeur,

–

doit avoir un sens (donc une valeur) pour chacune des occurrences de l’entité.

 Exemple

Client N_client Nom Prénom

Entité Propriétés

Représentation graphique d’une entité comportant trois propriétés 67

Modèle conceptuel de données (MCD) Règles concernant les attributs Règle 1

Une propriété ne peut en aucun cas être partagé par plusieurs entités/associations. Règle 2 Une propriété est une donnée élémentaire, ce qui exclut des données calculées ou dérivées.

Règle 3 Une entité et ses propriétés doivent être cohérents entre eux (i.e. ne traitent qu’un seul sujet).

68

Modèle conceptuel de données (MCD) Occurrence: entité Elément particulier d’une entité, identifiable de façon unique (instance)

 Deux occurrences de l’entité ne peuvent pas avoir la même valeur d’identifiant.  Exemple L’entité client1 dont le N° est 06464M est une occurrence de l’entité client Client 1

Client 2

064646M Dupont Frank 23 BD zola

012646M Revaud jerome 2 BD alpha 69

Modèle conceptuel de données (MCD) Identifiant: entité Attribut ou groupe d’attributs permettant d’identifier chaque occurrence d’une entité.

Règle 4

Chaque entité possède au moins un identifiant, éventuellement formé de plusieurs propriétés.

 Exemple Client N°client Nom Prénom Adresse

Identifiant simple

70

Modèle conceptuel de données (MCD)  identifiant : entité (suite)

 Il existe 2 types d’identifiants: simple et composé  Un identifiant est simple s’il est formé d’une seule propriété.  Un identifiant est composé s’il est formé de plusieurs propriétés,

 Exemple:  Entité avec identifiant composé

Appartement N°Appt Adresse Superficie

Identifiant composé

71

Modèle conceptuel de données (MCD)

 Dictionnaire de données  Un dictionnaire de données définit les informations, entités et propriétés de l'entreprise, et en les gérant au sein d'un MCD



Les dictionnaires de données assurent la cohérence d'utilisation en fournissant une définition unique pour toutes les données utilisés dans l'entreprise. Ils sont utilisés pour standardiser le contenu, le contexte et la définition des données ainsi que pour assurer la cohérence et la réutilisabilité.

72

Modèle conceptuel de données (MCD)

 Dictionnaire de données  Il s'agit de recenser les

différentes données, sachant que l'on distingue 3

types de données : 1. Données élémentaires : Elles ne sont pas obtenues par calcul à partir d'autres données. Exemple : On donne la quantité, le prix de l'article, calculer le coût total. La quantité et le prix sont des données élémentaires 2. Données calculées: Elles résultent d'un calcul effectué à partir d'autres données. Exemple : Le coût total est une donnée calculée (= qte * prix unitaire ). 3. Données paramètres: C'est une donnée qui ne prend qu'une unique valeur. Exemple : L'entreprise s'appelle PVF. La donnée nom de l'entreprise est une donnée qui ne prend qu'une seule valeur : PVF. Il s'agit donc d'une donnée paramétrable. 73

Modèle conceptuel de données (MCD)

 Dictionnaire de données (exemple) Définit pour chaque donnée son type, sa nature ( élémentaire, calculée, paramètre), sa description et les règles de calcul concernant les données calculées )

74

Modèle conceptuel de données (MCD)

Association Lien logique entre entités dont le type est défini par un verbe et une liste éventuelle de propriétés

 On appelle collection de l’association l’ensemble des entités qu’elle relie.

Règle 5 Une propriété peut être placée dans une association uniquement lorsqu’il dépend de toutes les entités liées par l’association.

75

Modèle conceptuel de données (MCD)

 Association : exemple Nom de l’association Client

N°client Nom Prénom Adresse

Commande Effectuer Date Commande

N°Commande Date livraison Total commande

Extrémités de l’association collection de l’association

76

Modèle conceptuel de données (MCD)  Association : identifiant  Il est implicite ! – C’est un ensemble composé des identifiants de la collection de l’association.

Règle 6 La concaténation des identifiants des entités liés à une association constitue l’identifiant de cette association (cet identifiant n’est pas mentionné sur le modèle (il est implicite).

 Exemple: – l’identifiant de l’association « effectuer » est le couple (N° client, N° commande)

Client N°client Nom Prénom Adresse

Commande Effectuer

N°Commande Date Commande Date livraison Total commande

77

Modèle conceptuel de données (MCD)  Association : cardinalités (1) Contrainte inscrite à chaque extrémité d’une association comportant un couple de valeurs (min-max) qui établit, pour chaque entité de l’association, le nombre minimum et maximum d’occurrences d’une association auxquelles elle peut participer

 Exemple – Un client peut effectuer de 0 à n commande, mais une commande ne peut être effectuer que par un seul client

Source

Sens de lecture

Client N°client Nom Prénom Adresse

Destination Commande

(0,n)

Effectuer

(1,1)

N°Commande Date Commande Date livraison Total commande 78

Modèle conceptuel de données (MCD)  Association : cardinalités (2) Règle 7&8 Règle 7: L’expression de la cardinalité est obligatoire pour chaque patte d’une association Règle 8: Une cardinalité minimal est toujours 0 ou 1, et une cardinalité maximale est toujours 1 ou n

 Remarques – Une cardinalité maximale de 0 n’a pas de sens – Si une cardinalité maximale est connu et vaut 2, 3 ou plus, alors nous considérons qu’elle est indéterminée et vaut n – Les cardinalités minimales qui valent plus de 1 sont modélisées par 1  Les seules cardinalités admises sont: cardinalités

signification

0,1

Au plus un

1,1 (ou 1)

Un seul

0,n (ou *)

Un nombre indéterminé

1,n

Au moins un 79

Modèle conceptuel de données (MCD)  Association : cardinalités (2)

Une extrémité sans contrainte aura pour cardinalité (0,n)

Client N°client Nom Prénom Adresse

Commande (0,n)

Effectuer

(1,1)

N°Commande Date Commande Date livraison Total commande

80

Modèle conceptuel de données (MCD)

 Association : cardinalités (3)

Client

N°client Nom Prénom Adresse

Commande (0,n)

Effectuer

(1,1)

N°Commande Date Commande Date livraison Total commande



Sur l’extrémité client, le 0 signifie que le client peut ne pas être reliée à la commande lors de sa création.



Le 1 en minimum de l’extrémité commande signifie qu’en aucun cas on ne peut créer une occurrence de l’entité commande sans la relier en même temps à une occurrence de l’entité client…Cette dernière doit donc avoir été créée avant !

81

Modèle conceptuel de données (MCD)  Occurrence d’une association

Une occurrence d’une association relie une seule occurrence de chacune des entités participant à l’association  Exemple:  Le client 1 effectue la commande 1  Le client 2 effectue la commande 2  La commande 1 est effectuée par le client 1  La commande 2 est effectuée par le client 2

Commande

Client N°client Nom Prénom Adresse

(0,n)

Effectuer

(1,1)

N°Commande Date Commande Date livraison Total commande

82

Modèle conceptuel de données (MCD)  Règles absolues!! (1)

Une association binaire de cardinalité minimale et maximale égale à un ne peut en aucun cas porter de propriétés ! Entité1 N°Entité 1 (0,n) Nom Entité 1 Prénom Entité 1 etc

Entité2 Association Attribut

(1,1)

N°Entité 2 Nom Entité 2 Prénom Entité 2 etc

Faux 83

Modèle conceptuel de données (MCD)  Règles absolues!! (2)

Une association binaire ne peut en aucun cas porter des cardinalités 1,1 des deux extrémités !

Entité2

Entité1 (1, 1) N°Entité 1 Nom Entité 1 Prénom Entité 1 etc

Association

(1,1)

N°Entité 2 Nom Entité 2 Prénom Entité 2 etc

Faux 84

Modèle conceptuel de données (MCD)

 Les associations plurielles

Deux mêmes entités peuvent être plusieurs fois en associations

Personne (0,n) Nom Prénom Adresse

(0,n)

Être l’auteur

(1,n)

Avoir critiqué (0,n)

Livre Titre Editeur

85

Modèle conceptuel de données (MCD)  Les associations réflexives

Une association réflexive est une association reliant des occurrences de la même entité

Personne N° Nom Prénom Adresse

Parent

(0,n)

Être parent

Enfant

(1,n)

86

Modèle conceptuel de données (MCD)  Les associations ternaires

Une association ternaire est une association qui décrit un lien sémantique entre trois entités A

(0,n)

Association

idA

(0,n)

B idB

(0,n) C idC

87

Modèle conceptuel de données (MCD)  Les associations ternaires

Créneau horaire

(0,n)

Projeter

N° Créneau Date Heure de début

Salle (1,n) N° Salle Capacité

(0,n) Film N° Film Titre Durée

88

Modèle conceptuel de données (MCD)  Les associations ternaires: décomposition  On remplace l’association ternaire (ou n-aire) par une entité et on lui attribut un identifiant  On crée des associations binaires entre la nouvelle entité et toutes les autres entités de la collection de l’ancienne association  La cardinalité de chacune des associations binaires crées est 1,1 du côté des entités créé et 0,n ou 1,n du côté des entités de la collection de l’ancienne association

89

Modèle conceptuel de données (MCD)  Les associations ternaires Créneau horaire N°créneau Date H de début

Salle 0,n

1,n

N°Salle Capacité

Projeter 0,n

Film

Projection

N°Film Titre Durée

N°projection Tarif

Salle N°Salle Capacité

1,1

Créneau h

Avoir lieu 0,n dans N°créneau

Date Heure de début

1,1

Concerner

Film 0,n

N°Film Titre Durée

90

Contrainte d’intégrité fonctionnelle (CIF)  Relation binaire Une voiture n’appartient qu’à une personne Voiture (1,1)

Appartenir

(0,n)

Immatriculation Modèle

Personne CIN

Soit voiture personne Une contrainte d’intégrité fonctionnelle (CIF) se définit par le fait que l’une des entité participant à l’association est complétement déterminée par la connaissance d’une ou plusieurs autres entités participant dans cette même association Représentation

flèche

Voiture (..,1)

Appartenir

Personne

91

Contrainte d’intégrité fonctionnelle (CIF)  CIF sur une relation binaire  Représentation graphique des CIF



Exprime qu’à partir d’une occurrence d’une entité, lui correspond (au plus) une seule occurrence de l’autre entité - La cardinalité maximum = 1 - Et l’existence d’une dépendance. Ces relations seront couramment appelées relations binaires fonctionnelles 92

Contrainte d’intégrité fonctionnelle (CIF)  CIF sur une relation binaire  Exemple - 1 membre du personnel est affecté à 1 seul établissement (affecter ne renvoie qu’une valeur) - La flèche traduit ici une dépendance de Personnel envers Etablissement - La flèche n’indique donc pas un sens de lecture mais le sens de la dépendance

93

Contraintes intra-relations  

Exclusivité de participation d’une entité à plusieurs relations: Contrainte d’exclusion – Exemple: – Une personne donnée ne peut pas à la fois suivre des cours et en donner (même si les cours sont différents). Cette contrainte est marquée par un pivot (lui-même symbolisé ici par des pointillés) permettant de limiter la contrainte aux personnes.

– Mais un cours peut à la fois être suivi et donné ! (Absence de pivot côté COURS). 94

Contraintes intra-relations 

Exclusivité de participation d’une entité à plusieurs relations: – Exemple: – un article peut être acheté chez des fournisseurs ou approvisionné par des UNITES; il ne peut être à la fois acheté et approvisionné

– Par rapport à ARTICLE, acheter et approvisionner sont mutuellement exclusives 95

Contraintes intra-relations

96

Contraintes intra-relations 

Totalité de participation d’une entité à plusieurs relations (ou inclusif): – Exemple: Tout VEHICULE est au minimum relié soit à un CONTRAT par relation COUVRIR, soit à un SINISTRE par la relation IMPLIQUER, soit les deux:

97

Contraintes intra-relations

98

Contraintes intra-relations 

Simultanéité de participation d’une entité à plusieurs relations (ET logique): – Exemple: une commande portant sur des ARTICLEs est obligatoirement passée par un client et réciproquement.

99

Contraintes intra-relations 

Inclusion de participation d’une entité à plusieurs relations: – Exemple: Une personne qui effectue un PRÊT doit avoir souscrit un ABONNEMENT

Par rapport à l’entité PERSONNE, la relation EFFECTUER est incluse dans la relation SOUSCRIRE

100

Contraintes intra-relations

101

Contraintes intra-relations 

Contraintes d’inclusion de relations sur d’autres relations: – Exemple: Tout professeur qui enseigne une matière à une classe donnée, est qualifié pour cette matière. On a ici une contrainte d’inclusion de la relation ENSEIGNER sur la relation QUALIFIER, que l’on modélisera de la façon suivante:

Par rapport aux entités MATIERE et PROFESSEUR, la relation ENSEIGNER est incluse dans la relation QUALIFIER 102

Contraintes intra-relations (CIF) – A retenir

103

Contraintes intra-relations (CIF)  CIF sur une relation n-aire  CIF n’englobant pas la totalité de la collection: – Un cours ne peut pas avoir lieu que dans une seule salle – Courssalle – L’enseignant n’étant pas compris dans cette contrainte peut faire plusieurs cours dans la même salle – 2 cours dans 2 salle différentes – Mais dans tous les cas 1 seule salle pour 1 cours

104

Contraintes intra-relations (CIF)  CIF sur une relation n-aire (décomposition)  CIF n’englobant pas la totalité de la collection: – L’affectation de la salle est indépendante de l’enseignant – On peut décomposer « faire cours » en « assurer le cours » et « trouver une salle » pour le cours

105

Contraintes intra-relations (CIF)  Décomposition par dépendance fonctionnelle  Avant décomposition

DF: chaque ENTREPRISE n’effectue qu’un TYPE DE TRAVAUX



Après décomposition

106

Contraintes intra-relations (CIF)  Décomposition par cardinalité 1,1  Une cardinalité maximale de 1 dans une relation implique, par définition, des dépendances fonctionnelles  Avant décomposition



Après décomposition

107

Contraintes intra-relations (CIF)  Décomposition par cardinalité 0,1  Avant décomposition



Après décomposition



Dans le cas d’une cardinalité (0,1), nécessité de rajouter une contrainte de simultanéité

108

Conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  L’héritage  



S’impose dans 2 cas : Spécialisation : permet de modéliser dans l'ensemble des occurrences d'une entité, des sous-ensembles (appelées entités sous-types) présentant des spécificités. Généralisation : ayant identifié 2 entités fortement similaires on crée une entité qui factorise les propriétés communes. Entité générique Liste des propriétés communes

Entité spécifique Liste des propriétés spécifiques 109

Modèle Conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Spécialisation simple 

 

Permet de modéliser, dans l’ensemble des occurrences d’une entité, des sous-ensembles d’occurrences présentant des spécificités Ces spécificités peuvent porter sur des propriétés, des relations ou des appellations L’entité sous-type hérite de toutes les propriétés de l’entité sur-type y compris de son identifiant

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Spécialisation simple (exemple)     

Un assuré peut être une entreprise, un particulier ou les deux On distingue trois entités : ASSURE, ENTREPRISE, PARTICULIER Un assuré a les propriétés N°assuré, Nom, Adresses, CP, Ville et Téléphone Un assuré particulier a en plus une profession et une classe d’âge Une entreprise a un N°SIREN et une forme juridique.

111

Modèle conceptuel de données (MCD) - Spécialisation/généralisation : Héritage

112

Modèle conceptuel de données (MCD) - Spécialisation/généralisation : Héritage

113

Modèle conceptuel de données (MCD) - Spécialisation/généralisation : Héritage

114

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Contraintes sur spécialisation  Expriment les participations des occurrences de l’entité sur-type aux entités sous-types  Types de contraintes :  Pas de contraintes  Exclusivité  Totalité

 Partition

115

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Contraintes sur spécialisation

116

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Contraintes sur spécialisation  Pas de contraintes, un assuré peut être particulier, entreprise, ni particulier ni entreprise, ou encore les deux à la fois

 X : Exclusivité, un assuré peut être soit entreprise, soit particulier, soit ni entreprise ni particulier mais pas les deux à la fois

 T : Totalité, tout assuré est un particulier, une entreprise, ou les deux

117

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Contraintes sur spécialisation  XT : Partition, tout assuré est soit entreprise, soit particulier

 Exemple

118

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Contraintes sur spécialisation  Exemple

119

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Héritage sans contrainte

120

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Héritage par exclusion (par disjonction)

121

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Héritage par totalité (par couverture)

122

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Héritage par partition (totalité et exclusion)

123

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Spécialisation sur types multiples  Notion proche de la notion de l’héritage, permet d’exprimer la situation suivante

 Représentation graphique

124

Conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation Modèle     

Généralisation Les entités sous-types préexistent Leur identification est indépendante de celle de l'entité sur-type Généralisation= mise en facteurs communs de propriétés Processus de perception qui va du particulier au général

125

Conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation Modèle  Restriction et sous types d’associations  Concernent la restriction de relations à des sous-types d’entités  Exemple :    

 

on dispose de trois entités : EMPLOYE, CHEF_PROJET, et PROJET CHEF_PROJET étant un sous-type de EMPLOYE. A l’entité PROJET, peuvent être affectés des EMPLOYES (via une association travailler) Plusieurs employés peuvent travailler sur un même projet, mais à un projet est affecté un seul chef de projet pour l’entité CHEF_PROJET, il y a une modification des cardinalités de l’association travailler. Un projet est gérée par un seul CHEF_PROJET, l’association gérer est une spécialisation de l’association travailler

126

Modèle conceptuel de données (MCD)

Entités

A retenir….

Règle 1 Toute entité présente dans un MCD doit obligatoirement comporter un identifiant Règle 2 Pour chaque occurrence d’une entité, chaque attribut ne peut prendre qu’une valeur Règle 3 Un attribut ne peut en aucun cas être partagé par plusieurs entités/associations Règle 4 Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou dérivées Règle 5 Deux occurrences de l’entité ne pourraient avoir la même valeur pour leur identifiant

127

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

A retenir….

Règle 6 Un attribut peut être placé dans une association uniquement lorsqu’il dépend de toutes les entités liées par l’association Règle 7 La concaténation des identifiants des entités liés à une association constitue l’identifiant de cette association (cet identifiant n’est pas mentionné sur le modèle (il est implicite). Règle 8 L’expression de la cardinalité est obligatoire pour chaque patte d’une association Règle 9 Une cardinalité minimal est toujours 0 ou 1 est une cardinalité maximale est toujours 1 ou n Règle 10 Une association binaire de cardinalité (1,1) ne peut en aucun cas porter de propriétés ! Règle 11 Une association binaire ne peut en aucun cas porter des cardinalités 1,1 des deux extrémités ! 128

Modèle conceptuel de données (MCD)  Règles portant sur les noms Dans un modèle entités-associations, le nom d’une entité, d’une association, ou d’un attribut doit être unique

Enseignant N° Enseignant Nom Prénom

Etudiant N° Etudiant Nom Prénom

Personne N° Personne Nom Prénom

Fusionner

Client N° client Nom Prénom Adresse de facturation

Facture 0,n

Correspondre

0,n

N° Facture Date Adresse de facturation

129

Modèle conceptuel de données (MCD)  Règles de normalisation des attributs un attribut multiple doit être remplacé par une association et une entité supplémentaires

Adresse

Employé N° Employé Nom Prénom Adresse principale Adresse secondaire N° tél domicile principale N° tél domicile secondaire N° portable

1,n

Normaliser

Employé

Habiter

N°adresse Code postal Ville

N°Employé 1,n Nom Prénom 1,n

Num tél Posséder 1,n

N°num tél type 130

Modèle conceptuel de données (MCD)  Règles de normalisation des attributs Un attribut est une donnée élémentaire, ce qui exclut des données calculées ou dérivées

Commande N° commande Date Montant total

Article 0,n

Contenir Quantité

0,n

N° Article Désignation Prix unitaire

131

Modèle conceptuel de données (MCD)  Règles de fusion/ suppression entités/associations Il faut factoriser les entités quand c’est possible

Généraliste N°généraliste Nom Prénom Adresse

Dentiste N°dentiste Nom Prénom Adresse

Ophtalmologue N°Ophtalmologue Nom Prénom Adresse

Médecin N°médecin Nom Prénom Adresse Spécialité

132

Modèle conceptuel de données (MCD)  Règles de fusion/ suppression entités/associations Il faut factoriser les entités quand c’est possible, mais l’introduction d’un attribut supplémentaire n’est pas toujours nécessaire Ecrivain Ecrire N°Ecrivain Nom Prénom Adresse

Ecrire

0,n

0,n

0,n

Personne 0,n

Abonné N°Ecrivain Nom Prénom Adresse

0,n

Livre

Emprunter 0,n

N°Livre Titre Editeur

Livre

N°Personne Nom Prénom Adresse

N°Livre Titre Editeur 0,n

0,n

Emprunter

133

Modèle conceptuel de données (MCD)  Règles de fusion/ suppression entités/associations Il faut factoriser les associations quand c’est possible Joueur de Tennis

0,n

N°joueur Nom Prénom Genre Classement

Joueur de Tennis N°joueur Nom Prénom Genre Classement

0,n

0,n 0,n

Jouer en tant que joueur 1

0,n

Jouer en tant que joueur 2

Jouer en tant que coéquipier 1

1,1

0,1

Jouer en tant que coéquipier 2

Jouer Type

1,n Match de Tennis

Match de Tennis 1,1

N°Match Type

0,1

N°Match Type

134

Modèle conceptuel de données (MCD)  Règles de fusion/ suppression entités/associations Il faut aussi se poser la question de l’intérêt de l’association quand les cardinalités maximale sont toutes de 1

Fournisseur N°fournisseur Nom Prénom Adresse

1,1

Fournisseur Travailler chez

Contact

N°contact Nom contact N°tél contact

1,1

Fusionner

N°fournisseur Nom Prénom Adresse Nom contact N°tél contact

135

Modèle conceptuel de données (MCD) - Types et sous types: spécialisation/généralisation  Spécialisation: Exemple • •

•

• • • •

La bibliothèque universitaire offre à ses adhérents la possibilité d’emprunter des livres, des périodiques, etc Les adhérents de la BU sont soit des étudiants, soit des enseignants. Tous les adhérents ont un numéro, un nom, un prénom, une adresse et un numéro de téléphone Un adhérent enseignant a en plus la structure à laquelle il appartient (un laboratoire, un département, etc), l’adresse de son bureau et enfin le numéro de téléphone de son bureau. Un adhérent étudiant a une filière et une année d’études Tous les documents de la bibliothèque ont un numéro, un titre et un éditeur. Les livres ont comme propriétés supplémentaires le nom de l’auteur et le nombre de pages Les dictionnaires sont comme propriétés supplémentaires le nombre de définitions. Les périodiques ont comme propriétés supplémentaires le nombre total d’auteurs Les thésards peuvent être à la fois étudiants et enseignants. Modélisez !! 136

Niveau conceptuel

Modèle Conceptuel de Communication (MCC)

Modèle conceptuel de communication (MCC)  Représente, au niveau conceptuel, les échanges d’information entre les acteurs  Première étape d’une étude de l’existant, pour modéliser les habitudes de

travail dans l’organisation concernée :  Délimiter le domaine étudié ;  Réduire la complexité en identifiant des sous problèmes traités individuellement ;  Identifier les acteurs externes et internes ;  Modéliser les échanges d’informations entre les différents acteurs.

138

Modèle conceptuel de communication (MCC)  Organisation: Etape 1 – La première étape de ce modèle est d'arriver à isoler le système en le

délimitant. Il s'agit donc de définir le système et les éléments externes avec lesquels il échange des flux d'information. Ces éléments extérieurs sont appelés acteurs externes (ou partenaires).

139

Modèle conceptuel de communication (MCC)  Organisation: Etape 2 – La seconde étape consiste à découper l'organisation en entités

appelées acteurs internes(ou domaines). – Lorsque les domaines d'une organisation sont trop importants, ils peuvent être décomposés eux-mêmes en sous-domaines.

– La dernière étape est l'analyse des flux d'information, c'est-à-dire la définition des processus.

140

Modèle conceptuel de communication (MCC)  Acteur – Représenté par un cercle libellé par le nom de l’acteur – L’acteur représente une unité active intervenant dans le fonctionnement d’un système opérant. Il peut : • Etre stimulé par des flux d’information ; • Transformer et émettre des flux d’information

– Un acteur « fait quelque chose », il est actif • Ex : Service comptabilité, Guichet ...

– Un acteur est un rôle plutôt qu’une personne physique (« Direction » et pas « Jean-Claude ») • Il peut être pertinent de modéliser séparément deux fonctions assumées par une même personne physique.

– On distingue les acteurs internes et externes. 141

Modèle conceptuel de communication (MCC)  Acteurs internes – Acteurs faisant partie du système d’information étudié. – Exemple : guichet, service informatique... – Si le système est complexe, on peut considérer un acteur interne comme un sous domaine et détailler ce sous-domaine dans un nouveau MCC.

142

Modèle conceptuel de communication (MCC)  Acteurs externes – Eléments externes avec lesquels le système échange des flux

d’information. – Exemple : client, fournisseur…

143

Modèle conceptuel de communication (MCC)  Flux d’information – Représenté par une flèche entre deux acteurs, étiquetée par le nom du flux. – Echange d’informations entre deux acteurs. – Exemple : documents, appels téléphoniques, données informatiques…

144

Modèle conceptuel de communication (MCC)  Diagramme de contexte – Le diagramme de contexte a pour but de représenter les flux d'informations entre l'organisation et les acteurs externes selon une représentation standard dans laquelle chaque objet port un nom : • L'organisation est représentée par un rectangle ; • Les acteurs externes sont représentés par des ellipses en pointillés ; • Les flux d'information sont représentés par des flèches dont l'orientation désigne le sens du flux d'information.

145

Modèle conceptuel de communication (MCC)  Diagramme conceptuel de communication – Ce diagramme (appelé aussi modèle conceptuel de flux) permet de compléter le diagramme de contexte en décomposant l'organisation en une série d'acteurs internes. – Les acteurs internes sont représentés par des ellipses, – Les messages internes sont représentés par des flèches.

146

Modèle conceptuel de communication (MCC)  Exemple – Gestion des sinistres dans une société d’assurance. A l’arrivée d’une déclaration de sinistre, on l’examine. Si la déclaration est recevable, on demande l’avis d’un expert, sinon on notifie le refus à l’assuré. Au retour de l’expertise et après réception de la facture du garage, on calcul le montant du remboursement et on envoie le chèque au client.

– Liste des acteurs : société d’assurance (int), client/assuré(ext), expert(ext, garage(ext) – Liste des flux : déclaration, demande, avis, facture, refus, avis expert, chèque

147

Modèle conceptuel de communication (MCC)  Exemple

148

Modèle conceptuel de communication (MCC)  Exemple  Lorsque le graphe comporte plusieurs acteurs internes on regroupes parfois tous ces acteurs en une même entité (correspondant au SI à étudier) et on ne garde que les flux en entrée et en sortie. C’est le graphe de flux contextuel.

149

Modèle conceptuel de communication (MCC)  Exemple  A partir du graphe contextuel on peut lister tous les événements en entrée du système (arrivée d’un flux sur un acteur interne) et tous les événements en sortie (départ d’un flux sur un acteur interne vers un acteur externe). C’est important pour caractériser le domaine d’études et pour la suite de l’analyse  Exemple:

 Evénement en entrée: arrivée d’une déclaration, d’un avis d’expert, d’une facture garage  Evénement en sortie: production d’un refus, d’un chèque, d’une demande d’avis

150

Modèle conceptuel de communication (MCC)  Remarques  On ne s’intéresse ni à l’ordonnancement des flux ni aux activités des acteurs. On fait abstraction de ces « détails »(pour le moment!)  Les flux entre acteurs externes sont ignorés  On se limite aux flux informationnels en ignorant les flux matériels . (ex. dépôt du véhicule)  Les flux sont point à point. Un document transmis à 2 destinataires donne 2 flux  Entre deux acteurs, il peut y avoir plusieurs flux dans le même sens s’ils sont

non simultanés, s’ils sont simultanés  Un autre domaine du SI est considéré comme un acteur externe (interne/externe est relatif au domaine d’étude) 151

Niveau conceptuel

Modèle Conceptuel de Traitement (MCT)

Modèle conceptuel de Traitement (MCT)  Décrit le fonctionnement du SI d’une organisation au niveau conceptuel: on fait abstraction des contraintes d’organisation et techniques; on ne décrit que les règles fondamentales de gestion (les invariants, « le métier » de l’organisation). Description la plus stable  Exemple  Les demandes d’ouverture du compte bancaire doivent suivre les règles de gestion

suivantes:  Règle1: Toute demande d’ouverture de compte doit faire l’objet d’un examen préalable  Règle 2: L’accord définitif d’ouverture ne peut être donné qu’après avis de la banque de France

153

Modèle conceptuel de Traitement (MCT)  Exemple

Ce découpage est une règle de gestion et pas un simple choix d’organisation de travail 154

Modèle conceptuel de Traitement (MCT)  Les concepts du MCT 

Le fonctionnement du SI est décrit par l’enchainement d’opérations:



Déclenchées selon certaines conditions de synchronisation (et, ou, …)



Portant sur des événements contributifs (internes ou externes)



Et produisant d’autres événements résultats (internes ou externes)

155

Modèle conceptuel de Traitement (MCT)  Notation graphique

Les acteurs sont facultatifs 156

Modèle conceptuel de Traitement (MCT)  Evénement contributif externe 

C’est un stimulis pour le SI qui provoque une réaction. Il doit être détectable par le SI



C’est un message c’est-à-dire un ensemble de données qui sont associés à un nouveau fait

 Opération 

Suite d’actions sans attente d’événement extérieur (« non interruptible »)



Déclenchée par un ou plusieurs événements contributifs internes ou externes



Produit des événements résultats internes ou externes, conditionnées par des règles d’émission

157

Modèle conceptuel de Traitement (MCT)  Les actions sont constituées: 

Des traitements appliqués aux données en entrée selon certaines règles



Des tâches de consultation et de mise à jour d’une base d’informations accessible.

 Synchronisation 

Condition exprimée sur les événements contributifs, qui détermine le déclenchement d’une opération.



S’exprime sous la forme d’une proposition logique utilisant des « et » et des « ou « (on évitera un maximum le « non », les non-événements n’étant pas toujours détectables par le SI)



Exemple: a ou (b et c) 158

Modèle conceptuel de Traitement (MCT)  Règles d’émission 

Elle caractérisent les résultats possibles de l’opération



Ex.



Les conditions d’émission des résultats d’une opération ne sont pas nécessairement exclusives (un résultat peut être émis par deux règles d’émission distinctes)



Les conditions d’émission portent souvent sur des cas d’anomalies (ex: une rupture de stock)

159

Modèle conceptuel de Traitement (MCT)  Types d’événement 

Evénement contributifs externes: proviennent de l’univers extérieur, sont traités par une opération conceptuelle (ex. arrivée d’un flux d’entrée, date de déclenchement)



Evénements contributifs internes: générés par une opération conceptuelle, contribuent au déclenchement d’une autre opération (état intermédiaire du SI ou état d’attente)



Evénements résultats: générés par une opération conceptuelle et destinés à l’univers extérieur (résultats externes) ou à d’autres opérations (résultats

internes)

160

Modèle conceptuel de Traitement (MCT)  Construction du MCT 

Jeton=occurrence d’événement



Quand la synchro devient vraie l’opération est exécutée. Un jeton et retiré de chaque entrée qui rend vraie la proposition et ajouté sur les sorties choisie (s)



On peut indiquer un nombre de jetons>1 à retirer ou à ajouter entre () à côté des arcs

Réfléchir en ces termes aide à construire des modèles « propres » 161

Modèle conceptuel de Traitement (MCT)  Construction du MCT 

Etape 1: Lister les acteurs et les flux



Etape 2: Etablir le graphe des flux (complet et contextuel)



Etape 3: A partir du graphe des flux, établir la liste de tous les événements en entrée et en sortie du SI



Etape 4: construire le MCT



Tout événement en entrée se retrouve en entrée d’une opération; il existe d’autres événements en entrée (ex: des dates conceptuelles)



Tout événement en sortie est produit par une opération



Le découpage en opérations est guidé par les règles de gestion

162

Modèle conceptuel de Traitement (MCT)  Exemple: Facturation

163

Modèle conceptuel de Traitement (MCT)  Exemple: Gestion des sinistres

164

Modèle conceptuel de Traitement (MCT)  Des schémas de base (1)

165

Modèle conceptuel de Traitement (MCT)  Des schémas de base (2)

166

Modèle conceptuel de Traitement (MCT)  Des erreurs de modélisation classiques 

Règles d’émission : elles doivent – Etre mutuellement exclusives : deux règles de la même opération ne peuvent pas être vraies en même temps ; – Couvrir tous les cas possibles.



Ne pas répéter les actions et les événements résultants ;



Problèmes de synchronisation – Il faut simplifier les synchronisations.



Problèmes structurel – Il faut éviter les chaînes d’opérations et les événements internes.

167

Modèle conceptuel de Traitement (MCT)  Des erreurs classiques

Les conclusions sont déjà dans les hypothèses. La condition d’émission doit décrire les résultats possibles du traitement des entrées 168

Modèle conceptuel de Traitement (MCT)  Des erreurs classiques  Dans un magasin, on encaisse le montant dû par le client lors de son passage en caisse. Pour certains gros clients dits « clients en compte », le paiement est différé. Le caissier envoie un avis de débit au service comptable

Contradiction entre événement d’entrée et condition de sortie 169

Modèle conceptuel de Traitement (MCT)  Des erreurs classiques  Si le propriétaire du véhicule est connu, son accord pour la destruction est nécessaire, sinon on peut s’en passer

Synchronisation logiquement incorrecte 170

Niveau logique

Niveau logique Modèle Logique de Données (MLD) 1. Terminologie 2. Schéma relationnel d’une BD 3. Règles d’intégrité structurelle 4. Dépendances fonctionnelles 5. Normalisation

Modèle logique de données (MLD)

 Le Modèle Logique des Données (MLD) est une étape intermédiaire pour passer du modèle E/A, qui est un modèle sémantique, vers une

représentation physique des données : fichiers, SGBD hiérarchique, SGBD réseau, SGBD relationnel.

 Nous nous limitons au seul MLD relationnel, qui prépare le passage aux SGBD relationnels.

Modèle logique de données (MLD) -Terminologie  Tables  Lorsque les données ont la même structure (par ex. renseignement relatifs à un client), on peut alors les organiser en tables dans lesquelles: – Les colonnes décrivent les champs en commun – Les lignes contiennent les valeurs de ces champs pour chaque enregistrement

 Exemple N° Client

Nom

Prénom

Adresse

1

Durand

Marie

2, rue la Paix

2 …

Motte …

Pierre …

7, rue Cler …

Modèle logique de données (MLD) -Terminologie  Tables, lignes, colonnes Relation Considérant N ensembles E1, E2,…En. Tout sous-ensemble du produit cartésien des N ensembles, noté E1 X E2 X…X En, constitue une relation

 Une table est une relation comportant des lignes (tuples) et des colonnes  Exemple:  E1  a, b et E2  c, d  , sont deux ensembles  le produit cartésien est: E1  E2  (a, c), (a, d ), (b, c), (b, d )  l’ensemble R1  (a, c), (a, d ) est un sous ensemble de E1  E2 il constitue une relation. E1 E2 R1  Les éléments de la relation sont appelés des tuples. a

c

a

d

b

c

b

d

Modèle logique de données (MLD) -Terminologie  Attribut, et domaine Attribut

Colonne d’une relation caractérisée par un nom

Domaine Ensemble des valeurs admises pour un attribut. Il établit les valeurs acceptables dans une colonne

 Exemple : – Domaine= {Entier, réel, booléen, caractère}

Modèle logique de données (MLD) -Terminologie  clef primaire  Les lignes d’une table sont uniqueil existe au moins une colonne qui sert à identifier les lignes: il s’agit de la clef primaire de la table  Les propriétés et conventions requises – La valeur vide (NULL) est interdite – La valeur de la clef primaire d’une ligne ne devrait pas changer au cours du temps – On souligne les clefs primaire dans un MLD

Modèle logique de données (MLD) -Terminologie  clef primaire clef primaire Ensemble minimal de colonnes qui permet d’identifier de manière unique chaque tuple dans une table (primary key)

 une clef primaire est simple si elle est composée d’une seule colonne  Une clef primaire composée peut être constituée de deux colonnes ou plus  Exemple – Client (N°, Nom, prénom, adresse) – Appartement( N°, adresse, superficie)

Modèle logique de données (MLD) -Terminologie  clef étrangère clef étrangère

une ou plusieurs colonnes dans une table qui a pour but d’assurer une liaison entre deux tables. La clef primaire de la première table est dupliquer dans la deuxième. On l’appelle aussi clef externe (Foreign key)

 Convention: – On fait précéder par # la clef étrangère

 Exemple Clients

Commandes

N° client Nom client Prénom client Adresse client

N° commande Date commande # N° client

Modèle logique de données (MLD) -Terminologie  Tables, lignes, colonnes, attribut, et domaine

Modèle relationnel

Modèle conceptuel

Table/relation

Entité

Ligne/tuple

Occurrence d’entité

Nom de colonne

Attribut d’entité

clef primaire/ étrangère

identifiant

Modèle logique de données (MLD) -Terminologie

Remarques Rq1:

Une même table peut avoir plusieurs clefs étrangères mais une seule clef primaire(éventuellement composée de plusieurs colonnes)

Rq2:

Une clef étrangère peut aussi être primaire (dans la même table)

Rq3:

Une clef étrangère peut être composée (c’est le cas si la clef primaire référencée est composée)

Rq4:

Implicitement chaque colonne qui compose une clef primaire ne peut pas recevoir la valeur NULL

Rq5:

Si une clef étrangère ne doit pas recevoir la valeur NULL, alors il faut le préciser dans la description des colonnes

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Schéma relationnel – Les tables sont appelées relations – Les liens entre les clefs étrangères et leur clefs primaires sont symbolisés par un connecteur

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Entité Règle Toute entité (dans un MCD) devient une table (dans un MRD) dans laquelle les attributs deviennent les colonnes et l’identifiant de l’entité constitue la clef primaire de la table

Client Codcli

se traduit par

Nomcli Adrcli

Entité

Client (codcli, nomcli, adrcli) Table

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Association binaire 1/1- 0/1 se traduit en ajoutant une clef étrangère (identifiant de l'entité de cardinalité (0,1) ) à la table provenant de l'entité dont la cardinalité est (1,1).

toujours un seul employé Département

Employé numemp nomemp

0,1

1,1

dirige

nudep nomdep

se traduit par Employé

Département

numemp nomemp

nudep #nuemp nomdep

Employé (nuemp, nomemp) Département (nudep, nomdep, #nuemp)

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Association binaire plusieurs à plusieurs se traduit par une nouvelle table dont la clef primaire est composée des identifiants des deux entités. Les éventuelles propriétés de l'association deviennent les attributs de cette table. Skieur Nomski spécialité

0,n

Classer rang

0,n

Compétition refcomp datcomp

se traduit par Classer ( #nomski, refcomp, rang)

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Association binaire un à plusieurs

Employé

Magasin N°Agence N° civique Rue Ville Code postal

Magasin N°Agence N° civique Rue Ville Code postal

1.n

Embaucher

1.1

N° Employé Nom Employé Prénom employé Salaire employé

Employé N° Employé Nom Employé Prénom employé Salaire employé

#N° Agence

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Association binaire (0,1)(0,1) Entité-association Entreprise

Salarie N°Salarie NomS Prenom

(0,1)

Est directeur

(0,1)

On duplique la clé d’une des tables dans l’autre Modèle relationnel

SALARIE(N°Salarie, NomS, PrenomS,#N°Entreprise) Ou Entreprise(N°Entreprise, NomE, Adresse,#N°Salarie)

N° Entreprise NomE Adresse

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Association n-aire (n>2) on crée une table ayant pour clef primaire les identifiants des différentes entités de l'association. Les éventuelles propriétés de l'association deviennent les attributs de la table.

Classe No_classe

Matière No_matiere

0,n

0,n Assure codsalle

0,n

Professeur No_prof

se traduit par Assure ( #no_classe, no_matiere, no_prof, codsalle)

Modèle logique de données (MLD) -Schéma relationnel d’une BD  Association réflexive

Personne N°matricule Nom Prénom

0..*

Epouse

Se marier

Date mariage 0..*

Personne N°matricule Nom Prénom

Se marier #N° matricule 1 , #N° matricule 2 Date mariage

Modèle logique de données (MLD) -Schéma relationnel d’une BD  L’héritage  L’héritage est traduit de 3 façons dans le modèle logique E1 P1 P2

ES1

ES2

PS1

PS2

Modèle logique de données (MLD) -Schéma relationnel d’une BD  L’héritage  

Première possibilité : intégration des sous-types dans la relation sur-type (les sous-types disparaissent). Avec un tel principe les propriétés spécifiques à chacun des sous-types ne seront pas valorisées pour certaines occurrences de la relation sur-type. E1 P1 P2

E1 (P1,P2, PS1, PS2)

ES1

ES2

PS1

PS2

Modèle logique de données (MLD) -Schéma relationnel d’une BD  L’héritage • •

Seconde possibilité : Intégration des propriétés figurant dans le sur-type dans tous les sous types (le sur-type disparaît). Cette solution entraîne une redondance importante des données du sur-type si il n’y a pas exclusion entre les sous-types. E1 P1 P2

ES1 (P1, P2, PS1) ES2 (P1, P2, PS2)

ES1

ES2

PS1

PS2

Modèle logique de données (MLD) -Schéma relationnel d’une BD  L’héritage • • •

Troisième possibilité : Conservation de l’entité sur-type et des entités sous types. Dans chacune des relations sous-types, l’identifiant de l’entité sur-type est intégré. Il est à la fois clé primaire de la relation et clé étrangère par rapport à l’entité sur-type.. E1 P1 P2

ES1 (P1, P2, PS1) ES2 (P1, P2, PS2)

ES1

ES2

PS1

PS2

Il est important de noter que quelque soit la solution adoptée, toute la puissance portée par le concept d’héritage est perdue dans le modèle relationnel.

Modèle logique de données (MLD) -Schéma relationnel d’une BD  L’héritage •

Exemple: Première possibilité Personnel Numéro Nom Prénom

Extérieur

Exemple d’occurrences : Internes 1 - Annick Lassus (14/06/1999) 2 – Armelle Mundubeltz (20/09/2000) Extérieur 3 – Bernadette Chaulet (CAP GEMINI)

Interne

SSII

DateEmbauche

PERSONNEL (Numéro, Nom, Prénom, SSII, DateEmbauche) num 1 2 3

Nom Lassus Chaulet undube

Prénom Annick Armelle Bernadette

SSII

DateEmbauche 14/06/1999 20/09/2000

CAP GEMINI

Modèle logique de données (MLD) -Schéma relationnel d’une BD  L’héritage •

Exemple: Seconde possibilité . Personnel Numéro Nom Prénom

Extérieur SSII

Interne DateEmbauche

EXTERIEUR(Numéro, Nom, Prénom, SSII) num 3

Exemple d’occurrences : Internes 1 - Annick Lassus (14/06/1999) 2 – Armelle Mundubeltz (20/09/2000) Extérieur 3 – Bernadette Chaulet (CAP GEMINI)

Nom

Prénom

undube

Bernadette

SSII CAP …

INTERNE (Numéro, Nom, Prénom, DateEmbauche) num 1 2

Nom

Prénom

Lassus Annick Mundub Armelle

dateEm 4/6/199 2/9/2000

Modèle logique de données (MLD) -Schéma relationnel d’une BD  L’héritage •

Exemple: Troisième possibilité Personnel Numéro Nom Prénom

Extérieur SSII

Interne DateEmbauche

INTERNE (Numéro#, DateEmbauche) num 1 2

dateEm 4/6/199 2/9/2000

Exemple d’occurrences : Internes 1 - Annick Lassus (14/06/1999) 2 – Armelle Mundubeltz (20/09/2000) Extérieur 3 – Bernadette Chaulet (CAP GEMINI) PERSONNEL (Numéro, Nom, Prénom) num 1 2 3

Nom

Prénom

Lassus Annick Mundub Armelle Chaulet Bernadette

EXTERIEUR (Numéro#, SSII) num 3

SSII CAP …

Modèle logique de données (MLD) -Règles d’intégrité structurelles

 Les règles d’intégrité sont les règles que doivent vérifiés les données contenues dans une base de données. Ces règles sont inhérentes au modèle de données  On distingue plusieurs règles structurelles correspondant au concepts: – Entité – Domaine – Clef (contrainte référentielle)

Modèle logique de données (MLD) -Règles d’intégrité structurelles Contrainte d’entité Contrainte imposant que toute relation possède une clef primaire et tout attribut participant à cette clef primaire est non nul

 Valeur nulle: valeur conventionnelle introduite dans une relation pour représenter une information inconnue ou inapplicable Contrainte de Domaine Contrainte imposant que la colonne d’une relation doit comporter des valeurs vérifiant une assertion logique

 L’ assertion logique est l’appartenance à une plage ou liste de valeurs:  Exemple: – Le domaine des salaires mensuels qui sont des réels compris entre 900 et 3000€ – L’âge d’une personne est compris entre 1 et 150

Modèle logique de données (MLD) -Règles d’intégrité structurelles Contrainte référentielle (clef étrangère) Contrainte d’intégrité portant sur une relation R1, consistant à imposer que la valeur connue d’un groupe d’attributs apparaisse comme valeur de clef dans une autre relation R2

Lors d'une insertion d’une valeur dans une relation, la valeur des attributs doit exister dans la relation référencée Exemple: – Insertion : Commande – Contrainte: le client correspondant doit exister

Lors d'une suppression dans la relation référencée , les tuples référençant ne doivent pas exister – Exemple: la suppression d’un client entrainera la vérification qu’aucun client ne référence une commande Clients

N° client Nom client Prénom client Adresse client

Commandes

N° commande Date commande # N° client

Spécialisation  Solution 1 : Duplication des attributs du surtype dans les sous types associés Entité-association

Modèle relationnel PERSONNE(n°personne,nom, age) ETUDIANT(n°personne,niveau, nom, age) ENSEIGNANT(n°personne, grade,nom,age)

 Respecte la logique  Gestion des duplicatas  Utilisation des triggers pour propager les modifications d’une entité à une autre

Spécialisation  Solution 2 : On duplique la totalité du contenu du surtype dans les sous types associés et on supprime les surtypes Modèle relationnel

ETUDIANT(n°personne,niveau, nom, age) ENSEIGNANT(n°personne, grade,nom,age)

 Simplifie la traduction  Redondance des données

Spécialisation  Solution 3 : Entité-association

 Respecte la logique  Manipulation des clés

Modèle relationnel

PERSONNE(n°personne, nom, âge) ETUDIANT(n°personne,niveau) ENSEIGNANT(n°personne, grade)

Spécialisation  Solution 4 : Fusion de toutes les informations et ajout d’une propriété pour identifier le type Modèle relationnel

 Simplifie la traduction  Nécessite de gérer le fait que les attributs peuvent être nuls  Solution utilisable quand les entités spécialisées ne comportent pas beaucoup d’attribut

Généralisation Entité-association

 Dans la généralisation les sous types ont leurs propres identifiants Modèle relationnel TIERS(n°tiers, raison sociale, adresse_administrative) CLIENT(n°client, adresse Livraison, #n°tiers) FOURNISSEUR(n°fournisseur, délai de livraison, #n°tiers)

 Création d’un clé étrangère unique dans les entités sous types

Modèle logique de données (MLD) -Dépendances fonctionnelles  Modèle relationnel de données normalisé  Un schéma relationnel normalisé doit répondre aux exigences minimales suivante: – Non redondance : un attribut n’appartient qu’une seule relation – Cohérence : les attributs qui décrivent le même objet appartiennent à la même table et dépendent chacun fonctionnellement et totalement de la clef primaire de la table

 On mesure la qualité d’une relation par son degré de normalisation: – – – –

La première forme normale, notée 1FN La deuxième forme normale notée 2FN La troisième forme normale, notée 3FN Forme normale de Boyce Codd, noté FNBC, etc

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelle entre deux attributs Un attribut B dépend fonctionnellement de l’attribut A, noté AB, si à une valeur de A correspond à une et une seule valeur pour B. On dit que A détermine B

 Plusieurs attributs peuvent apparaitre dans la partie gauche d’une DF : {A, B,C}D  Plusieurs attributs peuvent apparaître dans la partie droite d’une DF. Dans ce cas, il convient de considérer chaque DF en gardant la partie gauche et en faisant intervenir un seul attribut dans la partie droite

Modèle logique de données (MLD) -Dépendances fonctionnelles  Exemple de dépendances fonctionnelles 1.

(numPilote, jour)  nbHeuresVol est une DF, car à un couple (numPilote, jour) Correspond au plus un nombre d’heures de vol

2.

numPilote(nomPilote, fonction) ↔ numPilotenomPilote et numPilote fonction, qui sont deux DF.

3.

NomPilotefonction est une DF s’il n’y a pas d’homonymes dans les la BD

des pilotes. 4.

fonctionnomPilote n’est pas une DF, car à une fonction donnée correspondent éventuellement plusieurs pilotes

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelles élémentaires

Une DF (a,b)c est élémentaire si ni ac, ni bc ne sont des DF

 Exemples – RefProduitLibProduit est élémentaire – (NumFacture, RefProduit)QtéFacturé est élémentaire (ni la référence produit seule, ni le numéro de facture seul permettent de déterminer la quantité)

– (NumFacture, RefProduit)LibProduit n’est pas élémentaire puisque la référence du produit suffit à déterminer le libellé

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelles directes Une DF ac est directe si elle n’est pas déduite par transitivité, c’està-dire s’il n’existe pas de DF ab et bc

 Exemple Considérons Les dépendances fonctionnelles

(1) directe

N°ReprésentantNomReprésentant

(2) directe

(3) indirecte

 N°FactureN°Représentant est une DF directe

N°ReprésentantNomReprésentant est une DF directe N°FactureNomReprésentant n’est pas une DF directe puisqu’elle obtenue par transitivité

b

a

N°FactureN°Représentant et ,

c

1.3. Modèle logique de données (MLD): Dépendances fonctionnelles  Dépendances fonctionnelles: axiomes d’Armstrong Réflexivité Si b est un sous-ensemble de a alors ab est une DF. Si ab est une DF, alors (a, c)(b, c) est une DF.

Augmentation

Transitivité Si ab et bc sont des DF, alors ac est une DF. Si ab et ac sont des DF, alors a(b, c) est une DF.

Union

Pseudo-transitivité Si ab et (b, c)d sont des DF, alors (a,c)d est une DF. Décomposition Si a(b, c) est une DF, alors ab et ac sont des DF.

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelles: fermeture, couverture minimale Fermeture La fermeture F+ d’un ensemble de DF, F est l’ensemble des DF que l’on peut obtenir par applications successives des axiomes d’Armstrong.

 Exemple: – AB et BC donc AC – BC donc (B,D)(C,D)

(essentiellement la transitivité et pseudo-transitivité)

Couverture minimale Sous-ensemble minimum de DF élémentaires permettant de générer toutes les autres.

 Autre définition – Ensemble minimum de dépendances, équivalent à la fermeture transitive • peut ne pas être unique

Modèle logique de données (MLD) -Dépendances fonctionnelles  Graphe des Dépendances fonctionnelles  Pour chaque relation il faut recenser toutes ses DF élémentaires, on les représente sous forme d’un graphe orienté : « Graphe minimum des DF de la relation »  Une relation peut avoir plusieurs graphes minimum. Ils sont alors équivalents Exemple de graphe minimum:

Exemple de graphe non minimum:

R( A, B, C, D, E) E->A, E->B, E->C, E>D C->D E->D est déduite de E->C et C->D, Il faut supprimer E>D du graphe

Modèle logique de données (MLD) -Dépendances fonctionnelles  Exemple de Graphe des Dépendances fonctionnelles  LivraisonTot (N°f, adrF, N°p, typeP, qté)  N°fadrF : l’adresse d’un fournisseur ne dépend que du fournisseur

 N°p  typeP : le type d’un produit ne dépend que du produit  (N°f, N°p)  qté : la quantité totale livrée dépend du produit et du fournisseur

Graphe minimum de DF de la relation LivraisonTot

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelles et identifiants  Le graphe minimum des DF permet de trouver les identifiants de la relation

 L’identifiant de la relation est l’ensemble (minimal) des nœuds du graphe minimum à partir desquels on peut atteindre tous les autres nœuds (via les DF)  Exemple:  R(A, B, C, D, E) vérifiant les hypothèses: E->A, E->B, E->c, c->D

E est l’identifiant de R

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelles et identifiants: exemple  R (A, B, C, D, E, F, G)

 (F, G) est l’identifiant de R

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelles multivaluée (DM) Soit une relation R(X, Y, Z), il existe une dépendance multivaluée X-- >> Y, si à toute valeur de X correspond un ensemble de valeur de Y qui est totalement indépendant de Z

 Propriété  S’il existe la DM X-- >>Y alors il existe aussi X-- >>Z. On note : X-- >>Y|Z

 Remarque  DF est un cas particulier de DM

Exemple  La relation cours (nomC, prof, livre) contient une DM : nomC-- >>Prof| livre

Modèle logique de données (MLD) -Dépendances fonctionnelles  Dépendances fonctionnelles multivaluée (DM) : un autre exemple  Soit la relation Catalogue( N° Article, Taille, Couleur)  Hypothèse: il existe toutes les tailles et toutes les couleurs pour chaque article. Catalogue

Du faites des hypothèses, il existe une DM : N°Article-- >>Taille|Couleur

Chaque article existe pour chaque taille et toutes les couleurs et chaque article existe pour chaque couleur et chaque taille.

N° Article

Taille

Couleur

1

38

Noir

1

40

Noir

1

42

Noir

1

44

Noir

1

38

Bleu

1

40

Bleu

1

42

Bleu

1

44

Bleu

Modèle logique de données (MLD) -Normalisation  Première forme normale: 1FN Une relation est 1FN si tous ses attributs sont atomiques (ne sont pas décomposables)

ncomp

compagni e

nomPilote

sexe

typeAvion

immat

nbHeures Vol

1

Air-France

Bidal

F

CRJ

F-CLAR

600

1

Air-France

Bidal

F

A320

F-ROMA

345

1

Air-France

Bidal

F

A320

F-GLDX

120

2

Quantas

SanFilippo

G

A330

F-STEF

7500

2

Quantas

SanFilippo

G

A330

F-GLDX

250

2

Quantas

Soutou

G

A340

F-ABDL

2500

 Les tables relationnelles sont nativement toutes en 1FN, car les attributs de type tableau ne sont pas autorisés au niveau de la BD

Modèle logique de données (MLD) -Normalisation  Deuxième forme normale: 2FN Une relation est en 2FN si elle est en 1FN, et si chaque colonne qui ne fait pas partie d’une clef primaire dépend de la clef primaire

 Autrement dit, une table est en 2FN si – Elle est en 1FN – Une des 3 conditions suivantes est vérifiée • La clef primaire n’est formée que d’une seule colonne (un attribut) • La clef primaire contient toutes les colonnes de la table • Si la clef primaire a plus d’une colonne, une dépendance fonctionnelle ne doit jamais exister entre une partie de la clef et une autre colonne de la table

 Exemples: 

La relation Fournisseur (NF, NomProduit, NomF, Adresse, Tel, Prix) n’est pas en 2FN. La clef primaire est (NF, NomProduit) et NomF dépend d’une partie de la clef (NFNomF)

Modèle logique de données (MLD) -Normalisation  Comment normaliser 2FN?  Pour passer de la 1FN à la 2FN, il faut diviser chaque table ne satisfaisant

pas les critères en deux tables distinctes : – Créer une nouvelle table ayant pour clef la partie de la clef primaire dont dépend le ou les attributs, ainsi que ces attributs eux-mêmes. – Éliminer ces attributs (ceux qui ne font pas partie de la clef) de la table originale

Exemple – TÉLÉVISION (Marque, Modèle, ModeSon, Résolution) – Il y a donc une DF entre "Modèle" et "ModeSon", ainsi qu’entre "Modèle" et "Résolution" – Il faudra donc diviser cette table en deux de la façon suivante : – TÉLÉVISION (Marque, Modèle) – MODÈLETV (Modèle, ModeSon, Résolution)

Modèle logique de données (MLD) -Normalisation  Comment normaliser 2FN? (un autre exemple)  Soit la relation LivraisonTot (N°f, N°p, adrF, typeP, qté)  Le graphe minimum correspondant :

 La relation n’est donc pas en 2FN (N°f->adrF && N°p->typeP)  Il faudra diviser la table en 3 tables  R1(N°f, adrF)  R2(N°p, typeP)  R3( N°f, N°p, qté)

Modèle logique de données (MLD) -Normalisation  Troisième forme normale: 3FN Une relation est en 3FN si elle respecte la deuxième forme normale et si les DF entre la clef primaire et les autres colonnes sont directes

 Autrement dit, une table est en 3FN si – Elle est en 2FN – Aucune colonne ne faisant pas partie de la clef primaire ne dépend d’une autre colonne ne faisant pas partie non plus de la clef primaire • Les dépendances fonctionnelles entre deux colonnes ordinaires (ne faisant pas partie de la clef) sont interdites

B, C OK

A, B, C

Modèle logique de données (MLD) -Normalisation  Comment normaliser 3FN?  Pour passer de 2FN à 3FN, il faut – Diviser chaque table ne satisfaisant pas ce critère en deux tables. La nouvelle table aura comme clef la colonne dont provient la dépendance et comme colonnes, celles qui en dépendent. – Éliminer les colonnes dépendants de la table originale. La clef de la nouvelle table demeure dans l’ancienne en tant que clef étrangère

Exemple

VOITURE (NV, marque, type, puissance, couleur)  Cette table n’est pas en 3FN car Typemarque, puissance. Il faut donc décomposer cette table en deux. – VOITURE (NV, type, couleur) – Modèle(Type, Marque, puissance)

Modèle logique de données (MLD) -Normalisation  Comment normaliser 3FN? (un autre exemple)

 Soit la relation Fournisseur(N°fourn, ville, pays)  Le graphe minimum correspondant  La relation Fournisseur n’est pas en 3FN car ville->pays  La relation doit être décomposée en  F(N°fourn, ville)  G(ville, pays)

3F N

1.3. Modèle logique de données (MLD): Normalisation  Forme normale de Boyce-Codd (FNBC) Une relation est en FNBC si : - elle est en 1FN, et - si toutes les sources complètes de DF (la partie gauche de la DF) sont identifiants (candidats)

 Ou alors,  une relation est FNBC si  elle est FN3,  aucun attribut, ne dépend d’un attribut non clef

R(A, B, C)

Modèle logique de données (MLD) -Normalisation  Forme normale de Boyce-Codd (FNBC) (Définition 2) une relation est en forme normale de Boyce-Codd si les seules sources de dépendances fonctionnelles sont les clés candidates.

 Ceci implique que,  la relation est en troisième forme normale mais une relation peut être en troisième forme normale sans être dans la forme normale de BoyceCodd.

Ceci peut arriver  que si deux clés candidates se chevauchent (ont en commun une ou plusieurs attributs) et qu'une partie d'une des clés candidates dépend d'un attribut qui appartient à l'autre clé candidate.

Modèle logique de données (MLD) -Normalisation  Forme normale de Boyce-Codd (FNBC)  Exemple1 – Soit la relation R (N°_F , Produit, Adresse_F, Prix), avec comme ensemble de dépendances fonctionnelles • DF1 : N°_F  Adresse_F ; • DF2 : (N°_F ,Produit ) Prix.

Cette relation n'est pas en FNBC, car dans la DF1, la partie gauche N°_F n'est pas une clef entière. – Le relation peut être décomposé en deux tables: La décomposition est sans perte de • R1( N°_F , Adresse_F ) dépendance fonctionnelle et sans perte d’information. • R2( N°_F, Produit, Prix)

Modèle logique de données (MLD) -Normalisation  Forme normale de Boyce-Codd (FNBC)

 Exemple2 Considérons la relation suivante: Cours (Matiere, Classe, Professeur) o

complétée par les règles de gestion suivantes: • un professeur n'enseigne qu'une seule matière, • une classe n'a qu'un seul enseignant par matière

o desquelles on déduit les DF suivantes:  DF1: Matière, Classe  Professeur  DF2: Professeur  Matière

Cette relation est en 3NF, mais pas en FNBC à cause de la DF2

Cours (Matiere, Classe, Professeur)

Modèle logique de données (MLD) -Normalisation  Forme normale de Boyce-Codd (FNBC)  Exemple2 : suite   



On pourrait alors décomposer la table (Matiere, Classe, Professeur) en 2 tables: Spécialité (Professeur, Matière) Enseignant (Classe, Professeur) Remarque : la première DF (DF1: Matière, Classe  Professeur) est perdue.

Modèle logique de données (MLD) -Normalisation  Forme normale de Boyce-Codd (FNBC)  Exemple3: forme de Boyce Codd  Soit la relation Place( N°Etudiant, Matière, Rang) vérifiant les hypothèses suivantes:  DF1: (N°étudiant, Matière)Rang  DF2: (Matière, Rang)N°Etudiant

 2 identifiants candidats (N°étudiant, Matière) ou (Matière, Rang)  Place est en 3FN, et en FNBC.

Modèle logique de données (MLD) -Normalisation  Algorithmes de décomposition des DFs  Plusieurs algorithmes pour décomposer selon les DF  Algorithme 1 (d'après Heath)  R (A1, A2, A3, … An)  Tant qu'il existe une DF élémentaire non déduite faire :  Soit Ai  Aj la DF  Soient Ak,… Al les autres attributs qui dépendent directement de Ai : Ai  (Aj, Ak, …Al)  Remplacer R par  R1 (Ai, Aj, Ak, … Al)  R2 (Ai, attributs de R autres que Aj, Ak, …Al)

 Recommencer l'algorithme pour R1 et R2

Modèle logique de données (MLD) -Normalisation  Algorithmes de décomposition des DFs  Algorithme 1 : exemple R( F, G, A, B, C, D, E, H)

 Avantage –

relations en FNBC

 Inconvénients – – –

dépend de l'ordre selon lequel les DF sont traitées peut perdre des DF peut trop décomposer

Modèle logique de données (MLD) -Normalisation  Algorithmes de décomposition des DFs  Algorithme 2 (à partir des sources de DF)  R (A1, A2, A3, … An)

 Tant qu'il existe une source de DF élémentaire non déduite faire :  Choisir si possible une source dont toutes les cibles sont des extrémités terminales du graphe  Soient Ai la source et Ai(Aj, Ak,… Al) les DF  Créer la relation Ri (Ai, Aj, Ak, … Al)  Supprimer les attributs Aj, Ak, …Al de R

 Si aucune des relations Ri ne contient un identifiant de R alors ajouter la

relation : R0 (un identifiant de R)

Modèle logique de données (MLD) -Normalisation  Algorithmes de décomposition des DFs  Algorithme 2 : exemple R( F, G, A, B, C, D, E, H)

 Avantages – – –

relations en FN3 ne perd pas de DF ne perd pas d'information

 Inconvénient –

peut trop décomposer

Modèle logique de données (MLD) -Normalisation  La 4ème forme normale (4FN) La 4FN permet de séparer des faits multivalués indépendants qui auraient été réunis dans une même relation

 Définition : R est en 4FN si : – elle est en 1ère FN, et – si toute DF ou DM de R a pour source un identifiant entier de R

 Remarque : 4FN implique FNBC  Autre définition : R est en 4FN si elle est en FNBC et ne contient pas de DM

Modèle logique de données (MLD) -Normalisation  Décomposition de la 4ème forme normale (4FN)  Théorème de Heath n°2     

Si R(X, Y, Z) contient la DM X-->>Y|Z alors R est décomposée en : R1 = p[X,Y]R et R2 = p[X,Z]R (la décomposition est sans perte d'information).

 Exemple : Cours (nomC, prof, livre) est décomposé en : – CoursProf (nomC, prof) 4FN – CoursLivre (nomC, livre) 4FN

Le niveau organisationnel

Le niveau organisationnel  

Modèle Organisationnel de Données (MOD) Modèle Organisationnel de Traitement (MOT)

Modèle organisationnel de données (MOD)

 La modélisation organisationnelle des données prend en compte des éléments relevant de l’utilisation des ressources de mémorisation :  Choix des informations à mémoriser informatiquement.  Quantification des informations à mémoriser (volume et durée de vie).  Répartition des données informatisée entre unités opérationnelles

Modèle organisationnel de données (MOD)  Choix des informations à mémoriser  Il s’agit de distinguer, à partir des informations formalisées sur le MCD, celles qui devront être mémorisées informatiquement dans le système d’information informatisé (SII).

 Exemple  soit une entreprise de livraison constituée d'un siège social, d'un entrepôt et d'agences. Le siège qui s'occupe de tous les clients et de toutes les factures aura le modèle général comme vue externe.

MOD siège

Modèle organisationnel de données (MOD)  Exemple (suite)  L'entrepôt ne s'occupe que de la livraison à partir des ventes et possède un modèle sans contrat ni facture.

MOD site 1 Entrepôt

Modèle organisationnel de données (MOD)  Exemple (suite)  Une agence n'effectue que les livraisons et les factures et a un modèle sans contrat.

MOD site 2 Agence  Un site comprendra le modèle commande et facture et l'autre le modèle commande et livraison. L'organisation des données n'est pas par sousensembles cohérents du modèle principal tels que modèle contrat, modèle facture ou modèle livraison. Le découpage organisationnel est réalisé à partir des individus basés sur un site précis

Modèle organisationnel de données (MOD)  Quantification des information à mémoriser  La quantification prend en compte deux notions : 

Le volume : taille et nombre de chaque élément.

 La durée de vie : statistiques sur le nombre minimum, maximum et moyen

d’occurrences

concrètes

pour

chaque

entité

et

chaque

association. Par exemple on remplacera la cardinalité 1,n par 1,50 si on estime que la valeur maximum ne dépassera pas 50 ou bien donner une cardinalité moyenne.

Modèle organisationnel de données (MOD)

 Répartition des données informatisées  On va analyser au niveau du MOD la répartition concrète des données entre les unités opérationnelles de l’entreprise. Dans le cas des données non informatisées, il faudra préciser leur localisation. Dans le cas des données informatisées, on va préciser les droits des différents utilisateurs (les acteurs du MOT). Ces droits peuvent être :

 Lecture  Écriture  Création

 Suppression Chacun de ces droits s’appliquant aux entités, aux attributs, aux associations et à leurs occurrences.

Modèle organisationnel de traitement (MOT)  Point de départ  Les règles de gestion définies dans le nouveau MCT  Les nouvelles règles d’organisation: Qui?  Quel poste de travail assure le traitement  Contraintes de temps dues à l’organisation  Traitement manuel ou automatisé

Quand? Comment?

 Procédure  Chaque opération conceptuelle du MCT est décomposée en un ensemble de phases

Modèle organisationnel de traitement (MOT)  Phase  Ensemble de tâches dont l’enchainement est « non interruptible » compte tenu de l’organisation mise en place. Toutes les tâches d’une phase se déroulement:  Sur un même poste de travail (unité de lieu)  À un moment déterminé(unité de temps)  Avec des moyens homogènes – manuel / automatique (unité d’action)

 Exemple  Chaque jour à 16h le secrétariat exécute la phase saisie du dossier de candidature  Liste des tâches: 1) saisie des données, 2) m.à.j du fichier informatique ‘candidatures’, 3) classement du dossier papier

Modèle organisationnel de traitement (MOT)  Le poste de travail est caractérisé par :  Une fonction à assurer (gestion des stocks….)  Un lieu géographique  Un ensemble de moyens/ressources (personnel, matériel)

 La nature du traitement  Manuel  Conversationnel (traitement unitaire immédiat),  Par lots ou batch (traitement différé d’un lot de données).

 La période d’exécution: des contraintes l’organisation sont introduites (date, duré….). Ex: chaque jour à 17h, édition des factures.

de

temps

dues

à

Modèle organisationnel de traitement (MOT)  Evénement : en plus des événements conceptuels on ajoute les événements organisationnels  Événement de déclenchement de phase

Ex. date d’exécution d’une tâche  Événements internes traduisant des liens entre phases (événements intermédiaires, états d’attente)

Ex: dossier de saisi

 Autres concepts (synchronisations, règles d’émission): identiques au MCT; prennent en compte les règles d’organisation

Modèle organisationnel de traitement (MOT)  MOT (Schéma des phases)

Modèle organisationnel de traitement (MOT)  Exemple : Gestion des sinistres dans une assurance A l’arrivée d’une déclaration d’accident, le responsable du service de gestion des sinistres décide de la recevabilité et note son avis sur la déclaration. Il transmet la déclaration annotée au secrétariat du service qui saisit les éléments essentiels sur ordinateur. En fin de journée, on édite les demandes d’expertise et les notifications de refus Au retour de l’expertise, quelques jours plus tard, on enregistre sur un terminal la réponse de l’expert. On classe la réponse dans un dossier assuré Au retour de la facture du garage, on vérifie si le rapport de l’expert est arrivé; on enregistre la facture et on édite immédiatement la chèque destiné au client

Modèle organisationnel de traitement (MOT)  Tableau de décomposition en phases

Modèle organisationnel de traitement (MOT)  Tableau de décomposition en phases

Modèle organisationnel de traitement (MOT)  Fiche de description des phases

Modèle organisationnel de traitement (MOT)  A retenir… MOT= MCT + lieu + moment + nature

•

Lieu: – Qui exécute? Acteurs (MCC)

• Moment – Quand exécute-t-on l’opération? – Agencement temporel

•

Nature – Manuelle – Automatique – Interactive

Niveau physique

Modèle Physique des Données (MPD)

Niveau physique –

Définition des schémas

–

Manipulation des données

–

Contraintes d'intégrité

Niveau physique  Définition des schémas: création de tables Syntaxe1:

 Syntaxe2:

CREATE TABLE





[option1],



[option2],

CREATE TABLE … as

… Format

Type

Valeur numérique

INT, NUMBER(x) , NUMBER(x,y)

Chaîne de caractère

CHAR(n), VARCHAR2(n)

date

DATE

Texte de longueur inconnu

long

Niveau physique  Définition des schémas: création de tables Syntaxe1:

 Syntaxe2:

CREATE TABLE





[option1],



[option2],

CREATE TABLE … as

… Option

Signification

NOT NULL

obligation de donner une valeur

UNIQUE

Interdit deux même valeurs pour la même colonne

PRIMARY KEY

Clé primaire

REFERENCES

(col)

Clé étrangère, établit une relation avec une autre table via sa clé primaire

CHECK(condition)

Émet une condition sur une colonne

DEFAULT

Définit une valeur par défaut

Niveau physique  Définition des schémas: création de tables  CREATE TABLE EDITEURS (NumEditeur NUMBER (5) Nom CHAR(10)NOT NULL, Prénom CHAR(10));

PRIMARY KEY,

 CREATE TABLE OUVRAGES ( Numouvrage Number(5)PRIMARY KEY, Titre CHAR(30), NumEditeur Number(5)REFERENCES EDITEURS(NumEditeur), NbExemplaire Number(3) CHECK (NbEXemplaire>0) ); 

CREATE TABLE UNEXP As select *FROM OUVRAGES WHERE NbExemplaire=1

Niveau physique  Modification des schémas: Alter table

•

Ajout d’attributs : syntaxe ALTER TABLE ADD ( [option1],

[option2], …);

•

Exemple : ALTER TABLE Auteurs ADD (Nationalité

char(10)

NOT NULL);

•

Modification d’attributs: syntaxe ALTER TABLE MODIFY < colonne1 >

•

;

Exemple: ALTER TABLE Auteurs MODIFY Nationalité

char(100);

on ne peut pas diminuer la longueur d’une colonne contenant déjà des valeurs

Niveau physique  Modification des schémas: Alter table ADROP,

RENAME TO, DESC

Suppression d’une table : DROP TABLE Exemple : DROP TABLE nom_table; Renommer une table : RENAME TO Exemple : ALTER TABLE nom_table RENAME TO nom_table ;

Afficher le contenu d’une table : DESC Exemple : DESC nom_table;

nouveau_

Niveau physique  Contraintes d’intégrités

• Contraintes des attributs: NOT NULL : obligation de donner une valeur DEFAULT valeur par défaut CHECK (condition) : contrainte sur la valeur de la colonne UNIQUE: unicité

• Contraintes de clés primaires PRIMARY KEY : clé primaire

• Contraintes référentielles(clé étrangères) FOREIGN KEY : clé étrangère

Afficher le contenu d’une table : DESC Exemple : DESC nom_table;

Niveau physique  Contraintes d’intégrités

• Contraintes des attributs: CREATE TABLE personne ( num NUMBER nom VARCHAR2 (15), prenom VARCHAR2 (15), Pays VARCHAR2 (20) ville VARCHAR2 (20) Montréal','Laval','Saint-Jérôme'))

Afficher le contenu d’une table : DESC Exemple : DESC nom_table;

PRIMARY KEY, DEFAULT ‘Canada‘ CHECK (ville IN

Niveau physique  Contraintes d’intégrités

• Contraintes de clés primaire: CREATE TABLE Produit ( codeProduit NomProduit description );

NUMBER CONSTRAINT pk1 VARCHAR2(20) VARCHAR2 (30)

CREATE TABLE Medecin ( NumMedecin NUMBER(3) NomMedecin VARCHAR2(20) LaSpecialite VARCHAR2(20) );

PRIMARY KEY, NOT NULL,

PRIMARY KEY, NOT NULL, NOT NULL

Niveau physique  Contraintes d’intégrités

• Contraintes de clés primaire: CREATE TABLE Examen( NumMedecin NUMBER(3), NSS NUMBER(3), DateExamen date, PRIMARY KEY(NumMedecin, NSS, DateExamen) ); CREATE TABLE Resultat( NumEtudiant NUMBER(10,0), codeCours VARCHAR2(10), Note NUMBER(5,2), CONSTRAINT pk2 PRIMARY KEY(NumEtudiant,codeCours) );

Niveau physique  Contraintes d’intégrités

• Contraintes référentielles ( clés étrangères): create table Patient( NSS NomPatient Adresse NumMedecinTraitant ); create table Service( CodeService NomService ChefDeService (NumMedecin), NbLits Batiment );

NUMBER (3) PRIMARY KEY, VARCHAR2 (20) NOT NULL, VARCHAR2 (20) NOT NULL, NUMBER (3) references Medecin(NumMedecin)

NUMBER (3) PRIMARY KEY, VARCHAR2 (20) NOT NULL, NUMBER (3) references Medecin NUMBER(3) check ( NbLits>1), VARCHAR2 (15)

Niveau physique  Contraintes d’intégrités

•

Contraintes référentielles ( clés étrangères):

CREATE TABLE programme ( codePrg VARCHAR2(3) nomProg VARCHAR2(20) );

CONSTRAINT pk3 PRIMARY KEY,

CREATE TABLE etudiants ( NumAd NUMBER CONSTRAINT pk4 PRIMARY KEY, Nom VARCHAR2(20), Prenom VARCHAR2(20), codePrg VARCHAR2(3), CONSTRAINT fk1 FOREIGN KEY(codePrg) REFERENCES programme (codePrg) );

Niveau physique  Contraintes d’intégrités

•

Ajout de contraintes

ALTER TABLE Client ADD CONSTRAINT NC_pk PRIMARY KEY (NC); ALTER TABLE Achat ADD CONSTRAINT NC_FK FOREIGN KEY (NC) REFERENCES Client(NC); ALTER TABLE Client ADD CONSTRAINT check_NC CHECK (NC IN (1, 2,3)); ALTER TABLE Client ADD CONSTRAINT NC_unique unique(NC);

•

Suppression de contraintes ALTER TABLE Appt DROP CONSTRAINT CLE_APPT;

•

Suppression de contraintes référentielles DROP TABLE Achat CASCADE CONSTRAINTS : Permet la suppression de toutes les contraintes d’intégrité référentielles faisant référence à la clé primaire de la table supprimée

Introduction à l’UML

Diagramme de classe

Introduction à l’UML  Contraintes d’intégrités

•

UML (Unified Modeling Language) :

•

•autre langage de modélisation

•

langage dédié à l'objet

•

•plusieurs types de diagramme, dont un utile en bases de données :

•

le diagramme de classes

Introduction à l’UML  Lien traduction entre UML et Merise UML

Merise

Entité Identifiant Attribut 1 Attribut 2 …

Classe Attribut 1 Attribut 2 …

Méthodes

Introduction à l’UML  Lien traduction entre UML et Merise: association Merise

UML

Méthodes

Introduction à l’UML  Lien traduction entre UML et Merise: association Merise

UML

Lien vers 0 ou 1 : 0,1

Lien vers 0 ou 1 : 0..1

Lien vers 1 : 1,1

Lien vers 1 : 1

Lien vers 0 ou plusieurs : 0,n

Lien vers 0 ou plusieurs : *

Lien vers 1 ou plusieurs : 1,n

Lien vers 1 ou plusieurs : 1..*

Méthodes

Introduction à l’UML  Lien traduction entre UML et Merise: cardinalités Merise

UML

Méthodes

Introduction à l’UML  Lien traduction entre UML et Merise: cardinalités Merise

UML

Méthodes

Introduction à l’UML  Les plus d’UML: agrégation

Association particulière dans laquelle l’une des entités décrit un tout alors que l’entité associée décrit des parties. L’entité qui représente les tout est appelée composite, l’entité qui représente une partie du tout est appelée composant.

 Propriétés de l’agrégation

– A « contient » des instances de B – La suppression de A n’implique pas la suppression de B agrégation – L'élément agrégé peut être partagé

 Exemple:

A

Enseignant N° Enseignant

Méthodes Agrégat

Equipe de recherche Nom équipe Thématique

Département Nom Dept

•L’enseignant est un composant d’une (ou plusieurs) équipe de recherche • La disparition d’une équipe de recherche n’entraine pas la disparition d’un enseignant

B

Introduction à l’UML  Les plus d’UML: composition Une forme forte d’agrégation avec le composé qui à chaque moment a une possession exclusive des parties. Le temps de vie des parties coïncide avec celui du composé

Commande N°Commande Date Commande Date livraison Total commande

Composite

1

1,n Ligne de commande N°lig commande

Composant

Remarque 1:Dans une composition, la multiplicité du côté du composite est toujours à 1, car un composant doit appartenir à un seul et un seul composite Remarque 2: la création d’une occurrence d’un composant exige la présence d’un composite pour s’y associer. Remarque 3 : la fin de vie d’une occurrence de composite entraîne en cascade la fin de vie de toutes les occurrences des composants associés.

Introduction à l’UML  Association: héritage •

L’association d’héritage est employée d’abord pour assurer le respect d’une règle de modélisation appelée la règle d’homogénéité. Tous les attributs d’une entité sont pertinents à cette entité et éventuellement tous doivent posséder une valeur.

 Contre exemple – Remarque 1: Transgression de la règle d’homogénéité – Remarque 2: Certains employés ne sont pas syndiqués,

–

notamment les employés

cadres Remarque 3: les occurrences de l’entité représentant des employés non syndiqués ne pourront avoir de valeur pour No_syndiqué et Taux _cotisation_syndicale

Employé No matricule Nom Prénom No_syndiqué Taux _cotisation_syndicale

Introduction à l’UML  Association: héritage

 Exemple : Héritage et respect de la règle d’homogénéité –

– –

Remarque 1: L’entité Employé_syndiqué est une sorte d’entité Employé et qui hérite de tous les attributs de Employé Remarque 2: Toute occurrence de Employé possède une valeur pour chacun de ses 3 attributs. Remarque 3: Dans le cas de Employé_syndiqué chaque Occurrence possède une valeur pour les 5 attributs

Employé No matricule Nom Prénom

Employé Employé_syndiqué No_syndiqué Taux _cotisation_syndicale

Introduction à l’UML  Association: héritage Type d’association qui définit la structure d’une entité en fonction d’une autre. Une entité appelée le supertype identifie les attributs communs, une autre précise les attributs spécifiques à un sous-type de la première ; le sous-type hérite à la fois des attributs, dont l’identifiant, et des associations de son supertype

 – – –

Exemple : L’héritage porte sur les attributs et les associations Remarque 1: L’entité Employé_syndiqué hérite des attributs de Employé, elle hérite aussi de l’association avec Poste Remarque 2: Un employé_syndiqué est une sorte d’employé et tout employé occupe un poste. Remarque 3: Employé syndiqué est un sous-type de l’entité Employé

Employé No matricule Nom Prénom

Employé_syndiqué No_syndiqué Taux _cotisation_syndicale

Introduction à l’UML Diagramme de cas d’utilisation

Introduction à l’UML  Diagramme de cas d’utilisation Avant de développer un système, il faut savoir précisément à quoi il devra servir, c.à.d à quels besoins il devra répondre.

 Modéliser les besoins permet de :  Faire l’inventaire des fonctionnalités attendues  Organiser les besoins entre eux, de manière à faire apparaitre des relations (réutilisation possibles,…)

 Avec UML, on modélise les besoins au moyen de digrammes de cas d’utilisation.

282

Introduction à l’UML  Diagramme de cas d’utilisation  Un cas d’utilisation est un service rendu à l’utilisateur, il implique des séries d’actions élémentaires.  Notation:

 Un cas d’utilisation est déclenché par un événement extérieur au système appelé événement initiateur  Un cas d’utilisation possède un nom: celui de la fonctionnalité du système qu’il prend en charge  Un cas d’utilisation met en œuvre un dialogue entre le système et l’entité à l’origine de l’événement initiateur. Un cas d’utilisation est l’expression d’un service réalisé de bout en bout, avec un déclenchement, un déroulement et une fin, pour l’acteur qui l’initie. 283

Introduction à l’UML  Diagramme de cas d’utilisation: Description d’un cas d’utilisation  Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation.  Un simple nom est tout à fait insuffisant pour décrire un cas d'utilisation. Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune ambiguïté concernant son déroulement et ce qu'il recouvre précisément.

284

Introduction à l’UML  Diagramme de cas d’utilisation  Un acteur est une entité extérieure au système modélisé, et qui interagit directement avec lui  Notation:

 L’acteur est à l’origine des événements initiateurs reçus par le système  L’acteur dialogue par la suite avec le cas d’utilisation dont il est l’initiateur  L’acteur possède un nom: celui du rôle qu’il joue lors de son interaction avec le système  L’acteur n’est pas forcément humain. Il peut s’agir: o D’un autre système o D’un équipement 285

Introduction à l’UML  Diagramme de cas d’utilisation : Identification des acteurs  Exemple o « Pierre utilise le système pour gérer son agenda » o « philippe utilise aussi le système pour gérer son agenda. Mais philippe est aussi autorisé à administrer le système »

 Pierre n’est pas un acteur du système, philippe n’est pas un acteur du système  Le rôle « utilisateur » est un acteur du système  Le rôle « administrateur » est un acteur du système Ne pas confondre personne physique et rôle Une personne peut très bien assumer plusieurs rôles et réciproquement

286

Introduction à l’UML  Diagramme de cas d’utilisation: Acteurs principaux et secondaires  L’acteur est dit principal pour un cas d’utilisation lorsque l’acteur est à l’initiative des échanges nécessaires pour réaliser le cas d’utilisation.

 Les acteurs secondaires sont sollicités par le système alors que le plus souvent, les acteurs principaux ont l’initiative des interactions.

287

Introduction à l’UML  Diagramme de cas d’utilisation: Relations entre acteurs  Une seule relation possible: la généralisation/ spécialisation

288

Introduction à l’UML  Diagramme de cas d’utilisation :Acteurs et cas d’utilisation  L’interaction entre cas d’utilisation et acteur est représentée par une association, éventuellement orientée vers le sens de l’interaction  Une seule association est utilisée pour représenter l’ensemble des événements échangés  L’association peut comporter des cardinalités

289

Introduction à l’UML  Diagramme de cas d’utilisation :Dépendance entre cas d’utilisation  Il existe 3 types de dépendance entre cas d’utilisation: o Les dépendances d’utilisations (ou d’inclusion): mise en facteur de séquences d’événement communes o Les dépendances d’extension : Externalisation de séquences d’événement exceptionnelles o Les dépendances de généralisation: Généralisation/spécialisation de cas d’utilisation

290

Introduction à l’UML  Diagramme de cas d’utilisation : Dépendances d’inclusion  Indique qu’un cas d’utilisation utilise systématiquement et intégralement une séquence d’activités décrite dans un autre cas d’utilisation  Est représentée par une flèche pointillée étiquetée « include », pointant vers le cas d’utilisation utilisé

Cas d’utilisation 1 « include »

Cas d’utilisation 2 Acteur 1

Le cas d’utilisation 1 utilise systématiquement le cas d’utilisation 2

291

Introduction à l’UML  Diagramme de cas d’utilisation :Dépendances d’inclusion  Quand un cas est trop complexe (faisant intervenir un trop grand

nombre d’actions), on peut procéder à sa décomposition en cas plus simples.

292

Introduction à l’UML

 Diagramme de cas d’utilisation :Dépendances d’inclusion  On peut factoriser des comportements utiles à plusieurs cas d’utilisations

293

Introduction à l’UML  Diagramme de cas d’utilisation :Dépendances d’extension  Indique qu’un cas d’utilisation utilise facultativement ou sous certaines conditions une séquence d’activités décrite dans un autre cas d’utilisation  Est représentée par une flèche pointillée étiquetée « extend », pointant vers le cas d’utilisation étendu Cas d’utilisation 1

« extend »

Cas d’utilisation 2

Utilisateur

Le cas d’utilisation 2 est une extension du cas d’utilisation 1

294

Introduction à l’UML  Diagramme de cas d’utilisation : Dépendance de généralisation  Indique qu’un cas d’utilisation est une spécialisation d’un autre cas d’utilisation  Est représentée par une flèche « d’héritage » pointant du cas d’utilisation spécialisé vers le cas d’utilisation le plus général Cas d’utilisation 1

Acteur 1 Cas d’utilisation 2

Le cas d’utilisation 2 est une spécialisation du cas d’utilisation 1

295

Introduction à l’UML  Diagramme de cas d’utilisation : Dépendance de généralisation  Le paiement par carte bancaire est un cas particulier de paiement  Un virement est une sorte de paiement

 La flèche pointe vers l’élément général.  Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet.

Pr.Imane DAOUDI

296

Introduction à l’UML 

Diagramme de cas d’utilisation : Dépendance de généralisation  Permet de factoriser un comportement commun à un ensemble de cas d’utilisation proches  Le cas d’utilisation le plus général est dit abstrait si seuls les cas d’utilisation spécialisés sont exécutables Retirer argent

Utilisateur

Ouvrir compte chèque

Retirer argent avec ticket

Ouvrir compte

Ouvrir compte épargne

297

TD n°2

Pr.Imane DAOUDI

298