51 1 4MB
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 – Courssalle – 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 uniqueil 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é AB, 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) ↔ numPilotenomPilote et numPilote fonction, qui sont deux DF.
3.
NomPilotefonction est une DF s’il n’y a pas d’homonymes dans les la BD
des pilotes. 4.
fonctionnomPilote 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 ac, ni bc ne sont des DF
Exemples – RefProduitLibProduit 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 ac est directe si elle n’est pas déduite par transitivité, c’està-dire s’il n’existe pas de DF ab et bc
Exemple Considérons Les dépendances fonctionnelles
(1) directe
N°ReprésentantNomReprésentant
(2) directe
(3) indirecte
N°FactureN°Représentant est une DF directe
N°ReprésentantNomReprésentant est une DF directe N°FactureNomReprésentant n’est pas une DF directe puisqu’elle obtenue par transitivité
b
a
N°FactureN°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 ab est une DF. Si ab est une DF, alors (a, c)(b, c) est une DF.
Augmentation
Transitivité Si ab et bc sont des DF, alors ac est une DF. Si ab et ac sont des DF, alors a(b, c) est une DF.
Union
Pseudo-transitivité Si ab et (b, c)d sont des DF, alors (a,c)d est une DF. Décomposition Si a(b, c) est une DF, alors ab et ac 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: – AB et BC donc AC – BC 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°fadrF : 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 (NFNomF)
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 Typemarque, 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