SlideShare une entreprise Scribd logo
Conception et modélisation d’un système d’information
1 Proposé par A BENDAOUD
OFPPT/DRPS/ISGI LAAYOUNE
MODULE : Conception et modélisation
d'un système d'information
FILIERE : TECHNIQUES DE
DEVELOPPEMENT INFORMATIQUE
Proposé par : FORMATEUR A BENDAOUD
Conception et modélisation d’un système d’information
2 Proposé par A BENDAOUD
Sommaire
La conception d’un système d’information............................................................................................. 4
Plan...................................................................................................................................................... 4
Histoire ................................................................................................................................................ 4
Causes d’échec .................................................................................................................................... 4
Introduction......................................................................................................................................... 5
Merise???............................................................................................................................................ 5
Notion de système d’information de l’entreprise............................................................................... 5
Architecture et fonctionnement d’un système d’information............................................................ 6
Fonctionnement d’un système d’information .................................................................................... 6
Système d’information et système informatique ............................................................................... 6
Les trois cycles de Merise.................................................................................................................... 7
Cycle de vie en cascade................................................................................................................... 7
Étude préalable par domaine :........................................................................................................ 8
Étude détaillée par projet :................................................................................................................ 8
Cycle de vie en spirale ..................................................................................................................... 9
Courbe du soleil............................................................................................................................... 9
Les systèmes informatiques ............................................................................................................. 10
Résumé.......................................................................................................................................... 10
Cycles d’abstraction de conception des S.I ....................................................................................... 11
Modèle conceptuel des données .......................................................................................................... 12
Introduction au Modèle Conceptuel des Données ........................................................................... 12
La séparation des données et des traitements................................................................................. 12
1. Les données (ou informations)...................................................................................................... 12
a. L’interview ................................................................................................................................. 12
b. L’étude des documents internes............................................................................................... 13
c. L’étude des documents externes............................................................................................... 13
Les différents types d’informations .................................................................................................. 13
a.Les informations élémentaires et mémorisables....................................................................... 13
b. Les informations calculées ........................................................................................................ 13
c. Les traitements .......................................................................................................................... 13
Propriété (ou attribut)....................................................................................................................... 14
Conception et modélisation d’un système d’information
3 Proposé par A BENDAOUD
Constitution du dictionnaire des données............................................................................................ 15
Les entités.......................................................................................................................................... 16
Identifiant d’une entite ..................................................................................................................... 19
Relations ou Association ................................................................................................................... 20
Relation réflexive........................................................................................................................... 22
Cardinalités........................................................................................................................................ 22
L’identifiant d’une association .......................................................................................................... 25
Relation ternaire................................................................................................................................ 26
Transformation d’une relation en une entité ................................................................................... 27
Notion de Dépendance Fonctionnelle................................................................................................... 29
Dépendance fonctionnelle élémentaire............................................................................................ 29
Dépendance fonctionnelle élémentaire directe............................................................................. 30
Graphe de Dépendances Fonctionnelles........................................................................................... 30
PERSONNALISATION D’ASSOCIATIONS ............................................................................................. 31
Dépendances Fonctionnelles particulières et Représentations MERISE 2....................................... 33
Les formes normales ............................................................................................................................. 34
Introduction....................................................................................................................................... 34
Definition....................................................................................................................................... 34
Avantages et inconvénients .......................................................................................................... 35
La première forme normale : ........................................................................................................ 36
La deuxième forme normale ......................................................................................................... 36
La troisième forme normale.............................................................................................................. 38
Le Modèle logique de données ............................................................................................................. 39
Introduction....................................................................................................................................... 39
Problématique :................................................................................................................................. 39
Transformation d’un individu ou entité type.................................................................................... 39
Transformation d’une relation binaire (0,n)-(1,1) ou (1,n)-(1,1)....................................................... 40
Transformation d’une relation binaire (0,n)-(0,1) ou (1,n)-(0,1)....................................................... 42
Transformation d’une relation binaire (0,1)-(1,1)............................................................................. 43
Transformation d’une relation binaire (0,1)-(0,1)............................................................................. 44
Transformation d’une relation binaire (*,n)-(*,n)............................................................................. 45
Transformation d’une relation ternaire et supérieure quelles que soit les cardinalités .................. 46
Application des règles de passage sur une relation réflexive ........................................................... 50
Application des règles de passage sur une entité faible................................................................... 51
Conception et modélisation d’un système d’information
4 Proposé par A BENDAOUD
La conception d’un système d’information
PLAN
 Introduction
 Merise??
 Notion de système d’information de l’entreprise
 Architecture et fonctionnement d’un système d’information
 Système d’information et système informatique
 Les trois cycles de Merise
HISTOIRE
Il y ’a maintenant cinq siècles, Cristoforo Colombo, aventurier d’origine génoise, persuadé de la
rotondité de notre planète, élabora le projet déconcertant d’atteindre les Indes par voie maritime, en
se dirigeant vers l ’Ouest..
L ’Histoire nous enseigne qu’il n ’atteignit jamais cet objectif, mais découvrit à la place les Amériques,
la terre nouvelle!!!§
CAUSES D’ÉCHEC
1. Méconnaissance quasiment totale du sujet sur ces principaux aspects, les Indes et l ’Océan.
2. Incapacité à estimer la durée et les charges de la traversée (Conséquence directe de 1)
3. Inadaptation flagrante du système de contrôle.
4. Incapacité à maintenir la cohésion de l’équipage
5. C’est de croire qu’il n’y a que 4 causes d'échec d’un projet
Conception et modélisation d’un système d’information
5 Proposé par A BENDAOUD
INTRODUCTION
 La conception d’un système d’information n’est pas chose aisée puisqu’il faut réfléchir à
l’ensemble de l’organisation qui doit être mise en place. Pour y arriver, il est nécessaire de
concevoir des méthodes pour l’élaboration d’un modèle du S.I. On parle ainsi de
modélisation ou de représentation virtuelle de la réalité. Ce type de méthodes est appelé
Analyse. Il existe plusieurs méthodes d’analyse, une des plus connues est la méthode
MERISE.
MERISE???
 MERISE est une méthode qui permet l’élaboration d’un système d’information. Cette
méthode est basée sur un concept fondamental : la séparation des données et des
traitements, cela est motivé par le fait que les données ne sont changées que rarement, par
contre, les traitements le sont plus souvent (contrairement à des pratiques plus récentes de
modélisation orientée objet où l’on ne sépare plus les données et les traitements).
 La méthode MERISE a vu le jour en 1978, et elle a été mise au point par 2 sociétés
françaises : le CTI (Centre Technique d’Informatique) et le CETE (Centre d’Études Techniques
de l’Équipement).
NOTION DE SYSTÈME D’INFORMATION DE L’ENTREPRISE
 L’entreprise est un système complexe dans lequel transitent de nombreux flux
d’informations. L’objectif de la mise en place d’un S.I est de maîtriser ces flux par la collecte,
la mémorisation, la distribution de l’information (avec un temps de réponse rapide). Ce S.I
assurera le lien entre 2 autres systèmes de l’entreprise : le système opérant et le système de
pilotage.
Système de Pilotage
Système opérant
Système D’information
Conception et modélisation d’un système d’information
6 Proposé par A BENDAOUD
Le système de pilotage décide des actions à conduire sur le système opérant en fonction des objectifs
et des politiques de l’entreprise.
Le système opérant comprend toutes les fonctions liées à l’activité propre de l’entreprise : facturer
les clients, payer les salariés, gérer les stocks…
ARCHITECTURE ET FONCTIONNEMENT D’UN SYSTÈME D’INFORMATION
 Le S.I doit décrire (ou représenter) le plus fidèlement possible le fonctionnement du système
opérant. Pour cela, il doit intégrer une base d’information dans laquelle sont mémorisées : la
description des objets, des règles et contraintes du système opérant.
 Cette base doit évoluer, c’est pourquoi le S.I contient « le processeur d’information » ayant
pour but de piloter et contrôler les changements de la base.
FONCTIONNEMENT D’UN SYSTÈME D’INFORMATION
 Voici le schéma de l’architecture d’un S.I :
SYSTÈME D’INFORMATION ET SYSTÈME INFORMATIQUE
 Pour assurer un traitement automatisé de l’information du S.I à l’aide d’outils informatiques,
la méthode Merise propose la démarche d’informatisation suivante :
 Schéma directeur : représente la définition, de manière globale, de la politique
d’organisation et d’automatisation du S.I. Lors de cette étape, le S.I est découpé en sous-
ensembles (ou domaines) homogènes et indépendants, par exemple, les domaines achat,
vente…
Base
d’information
Processeur d’information
Faits et
événements
Faits de la base
d’information
Conception et modélisation d’un système d’information
7 Proposé par A BENDAOUD
LES TROIS CYCLES DE MERISE
MERISE propose une démarche de réalisation d'un système d’information (SI) qui consiste à traiter
un projet informatique en s'appuyant sur trois notions fondamentales:
 Vie du projet
 Suivi du projet, décision
 Formalisation du projet (différents niveaux d’abstraction)
Le système d'information est composé des moyens (humains et techniques) nécessaires au stockage
et au traitement de l'information d'une organisation.
Cycle de vie en cascade
Etude préalable
ou de faisabilité
Etude détaillée
Recette test en
chaîne
Mise en
exploitation
Réalisation
programmation
test unitaire
Maintenance
Conception et modélisation d’un système d’information
8 Proposé par A BENDAOUD
Faire une présentation générale du futur système de gestion (matérialisé par les
modèles des données et des traitements) et ce qu’il apporte comme améliorations par rapport au
système existant. Cette étude doit être réalisée en 4 étapes :
 Étape de recueil : analyser l’existant pour détecter les dysfonctionnements du système
actuel.
 Étape de conception : formalisé les nouvelles orientations permettant de modéliser le futur
S.I sur la base, d’une part, des critiques formulées sur le système actuel et d’autre part, des
orientations de la direction de l’entreprise.
 Étape d’organisation : définir le système futur au niveau organisationnel, c.-à-d. qui fait
quoi ?
 Étape d’appréciation : établir les coûts et délais de réalisation des solutions préconisées.
Au regard de cette ébauche du système futur, proposer divers scénarios. Chaque scénario doit
mentionner les éléments
Suivants :
 Matériels nécessaires.
 Logiciels nécessaires.
 Grands ensembles d'informations et principaux traitements retenus pour l'automatisation
(MCT et éventuellement ébauche du MCD).
Les problèmes éventuels ne sont perçus qu’à la mise en exploitation, d’où la préférence donnée au
cycle de vie en spirale
ÉTUDE DÉTAILLÉE PAR PROJET :
 D’une part, détailler les solutions préconisées par l’étude préalable, et d’autre part, rédiger
le dossier des spécifications (maquettes, algorithmes associés aux règles de gestion…)
permettant de définir le cahier des charges de l’utilisateur qui constitue la base de
l’engagement du concepteur vis-à-vis de l’utilisateur.
 Réalisation : Obtenir des programmes qui tournent sur un jeu d’essai défini par l’utilisateur.
 Mise en œuvre : Transmettre, d’une part, la recette définitive de l’application à l’utilisateur,
et d’autre part, former l’utilisateur.
 Maintenance : Faire évoluer l’application en fonction des besoins de l’utilisateur et des
avancées technologiques.
Étude préalable par domaine :
Conception et modélisation d’un système d’information
9 Proposé par A BENDAOUD
Cycle de vie en spirale
Courbe du soleil
Analyse
conception
Merise
Prototype
V1
Test Mise
au point
Conception
Prototype
V2
Test Mise
au point
Critique
(focus point)
Conception
Version
stabilisée
Critique
(focus point)
Prototype
V3
Critique
Modéles :
Données
Traitements
Flux
Interviews
Recueil
d’information
Conceptuel
Organisationnel
Opérationnel
Nouveau
modèle
Nouveau
système
d’information
Analyse de l’existant Critique Conception réalisation
Temps
Abstraction
Conception et modélisation d’un système d’information
10 Proposé par A BENDAOUD
LES SYSTÈMES INFORMATIQUES
 Ils comprennent, outre les S.I, les technologies de l’information, les ordinateurs, les
applications informatiques, les réseaux et autres systèmes permettant l’accès, l’analyse, la
création, l’échange,… de l’information.
 En définitive, la méthode Merise est considérée comme une méthode de conception des S.I
et non des systèmes informatiques, même si les S.I sont actuellement largement gérés par
des applications informatiques, les modèles Merise doivent être utilisées pour faciliter le
développement de ces applications en s’appuyant sur les technologies logicielles de B.D
relationnelles ou client/serveur.
 En guise de conclusion de cette introduction, on dira que l’on traitera au niveau de ce cours
les concepts Merise utiles aux descriptions statique et « dynamique » du S.I à automatiser
sur 3 niveaux d’abstraction :
Le niveau conceptuel
Le niveau conceptuel consiste à concevoir le SI en faisant abstraction de toutes les contraintes
techniques ou organisationnelles et cela tant au niveau des données que des traitements.
Le niveau conceptuel répond à la question Quoi ? (le quoi faire, avec quelles données).
Le formalisme Merise employé sera :
Le Modèle Conceptuel des Données (MCD).
Le Modèle Conceptuel des Traitements (MCT).
Niveau organisationnel :
Le niveau organisationnel a comme mission d’intégrer dans l’analyse les critères liés à l’organisation
étudiée. Le niveau organisationnel fera préciser les notions de temporalité, de chronologie des
opérations, d’unité de lieu, définira les postes de travail, l’accès aux bases de données…
Les questions posées, au niveau des traitements, sont :
Qui ?
Où ?
Quand ?
Le formalisme Merise employé sera :
Le Modèle Organisationnel des Données (MOD).
Le Modèle Organisationnel des Traitements (MOT).
Le niveau logique
Le niveau logique est indépendant du matériel informatique, des langages de programmation ou de
gestion des données. C’est la réponse à la question Avec quoi ?
Le formalisme sera :
 Le Modèle Logique des Données (MLD).
 Le Modèle Logique des Traitements (MLT).
Résumé
Conception et modélisation d’un système d’information
11 Proposé par A BENDAOUD
Le niveau physique
 Le niveau physique permet de définir l’organisation réelle (physique) des données. Il apporte
les solutions
 techniques, par exemple sur les méthodes de stockage et d’accès à l’information. C’est la
réponse au Comment ?
 Le formalisme employé sera :
 Le Modèle Physique des Données (MPD).
 Le Modèle Opérationnel et physique des Traitements (MOpT).
Tableau récapitulatif
Niveaux Données Traitements
Conceptuel Modèle Conceptuel des Données Modèle Conceptuel des
Traitements
Organisationnel Modèle Organisationnel des
Données
Modèle Organisationnel des
Traitements
Logique Modèle Logique des Données Modèle Logique des traitements
Physique Modèle Physique des Données Modèle Opérationnel et Physique
des
Traitements
- 2
CYCLES D’ABSTRACTION DE CONCEPTION DES S.I
Système d’information actuel
Modèle logique
Expression des Besoins
Modèle conceptuel
Modèle physique
Système d’information Automatisé
Conception et modélisation d’un système d’information
12 Proposé par A BENDAOUD
Modèle conceptuel des données
Les concepts de base
Modèle conceptuel des données
INTRODUCTION AU MODÈLE CONCEPTUEL DES DONNÉES
Une description détaillée d’un système d’information suppose, implicitement, une description
détaillée de l’ensemble d’objets, d’événements ou de concepts concernés par les traitements.
Le modèle conceptuel de données (MCD) décrit les objets, les événements, les concepts d’une
manière abstraite, sans réfléchir, à ce stade, aux possibilités de traitement par l’ordinateur. Dans
la suite, nous étudierons le modèle basé sur le couple entité - association.
Le Modèle Conceptuel des Données introduit la notion d’entités, de relations et de propriétés.
Nous allons commencer par voir certains aspects « théoriques » avant de plonger dans la
pratique. Il décrit de façon formelle les données utilisées par le système d’information. La
représentation graphique, simple et accessible, permet à un non informaticien de participer à
son élaboration. Les éléments de base constituant un modèle conceptuel des données sont :
 les propriétés ;
 les entités ;
 les relations.
LA SÉPARATION DES DONNÉES ET DES TRAITEMENTS
1. LES DONNÉES (OU INFORMATIONS)
L’information est l’émission ou la réception de signaux oraux ou écrits, sonores, visuels ou multimédias
dont le but est de déclencher les processus alimentant l’échange, base naturelle et indispensable de
l’animation de l’organisation.
Les informations se recueillent à l’intérieur du domaine à étudier. La liste d’informations est constituée de
plusieurs façons :
 l’interview ;
 l’étude des documents internes ;
 l’étude des documents externes.
Une des phases du recueil d’information est un entretien avec les différents acteurs de l’organisation. Cet
entretien permet de définir le périmètre de l’applicatif futur. Les informations orales sont classées et
a. L’interview
Conception et modélisation d’un système d’information
13 Proposé par A BENDAOUD
regroupées en parties distinctes. Ainsi, les informations concernant l’enregistrement des données de
l’organisation seront regroupées.
Les documents internes (factures, bons de livraison, ordres de fabrication) recèlent des informations qui
sont souvent omises lors des entretiens. Ces oublis sont dus au caractère automatique et récurrent de
ces informations.
Les personnes qui les manipulent au quotidien oublient souvent de les citer tant elles leur paraissent
évidentes.
L’étude des documents externes (factures des fournisseurs, bons de livraison fournisseurs...) tout
comme l’étude des documents internes permet de découvrir des informations oubliées lors des interviews
et de découvrir aussi quelques règles de gestion.
Pour ce recueil d’informations, il est nécessaire de respecter certaines règles pour éviter des erreurs
futures.
Avant d’ajouter une information, il est impératif de s’assurer qu’elle n’est pas déjà présente. Par
exemple, un numéro client peut apparaître sur un bon de livraison et sur une facture. Ce n’est pas la
peine de le répertorier deux fois.
De même, une information peut être synonyme d’une autre. Par exemple sur le bon de livraison il
apparaît « Codeclient » et sur la facture « Numéro Client ». Il est impératif de ne garder qu’une seule des
deux informations.
LES DIFFÉRENTS TYPES D’INFORMATIONS
Les informations élémentaires sont des informations dont les valeurs ne peuvent pas être inventées, elles
ne sont pas déductibles d’autres informations.
La propriété est une information élémentaire (par rapport au domaine étudié), c-à-d qu’elle ne peut
pas être déduite à partir d’autres informations.
Par exemple, un nom de client ou sa raison sociale ne peuvent pas être inventés.
Une quantité commandée ne peut pas non plus être inventée.
Une information doit être atomique, c’est à dire non décomposable. Par exemple si l’information Adresse
doit contenir « 36, rue de la paix 75000 Paris » celle-ci peut être décomposée en plusieurs informations
élémentaires :
Adresse ;
Code postal ;
Ville.
Chaque valeur prise par une information est appelée une occurrence. Par exemple, l’information Nom
peut avoir les occurrences suivantes : lBRAHIMI ;MOURAD.FAHMI
Les informations calculées sont déductibles des informations élémentaires.
Par exemple, le total d’une ligne de commande est le résultat de la multiplication du prix de vente hors
taxe et de la quantité commandée.
Ils sont collectés comme les informations via un processus d’interview et d’étude des documents.
b. L’étude des documents internes
c. L’étude des documents externes
a.Les informations élémentaires et mémorisables
b. Les informations calculées
c. Les traitements
Conception et modélisation d’un système d’information
14 Proposé par A BENDAOUD
Ils peuvent être de deux sortes :
 Automatiques ;
 Manuels.
Ils sont déclenchés par l’arrivée d’évènements.
La gestion des traitements sert à identifier les fonctionnalités selon une approche qui va du général au
particulier et qui définit leur découpage et leur enchaînement.
PROPRIÉTÉ (OU ATTRIBUT)
La propriété est une information élémentaire (par rapport au domaine étudié), c-à-d qu’elle
ne peut pas être déduite à partir d’autres informations.
Par exemple, si on considère le domaine de « la gestion des ventes d’une société
commerciale », les données :
 Référence article » ; « Désignation article »
 Prix unitaire HT ; Taux TVA
Sont des propriétés « pertinentes » pour ce domaine. En revanche, la donnée
« Prix unitaire TTC » n’est pas une propriété, car elle peut être déduite du PU-HT et du T-TVA.
Total n’est pas une propriété car il est calculé en fonction de la somme des PU*Qtt
Chaque valeur prise par une propriété est appelée occurrence. Par exemple, des occurrences
de « désignation article » sont : « ordinateur », « clavier », « souris »…
« «brahim », »ahmed », »ali », » fatima» se sont des occurrences de la propriété nom
 Une propriété est dite simple (ou atomique) si chacune des valeurs qu’elle regroupe n’est
pas décomposable.
 Par exemple, la propriété « Adresse », dont un exemple d’occurrences est donné ci-dessous,
n’est pas élémentaire car elle peut être décomposée en 3 propriétés : la rue, le code postale
et la ville :
 125, Boulevard Abdelmoumen 20000 Casablanca.
Remarque
Dans le MCD, on doit faire apparaître toutes les propriétés identifiées par leurs noms qui
doivent être explicites. De plus, il doit y avoir une parfaite correspondance (bijection) entre
l’ensemble des noms et l’ensemble des propriétés, cela donne les règles suivantes :
 Il faut exclure les synonymes : 2 noms différents pour identifier la même propriété.
 Il faut exclure les polysémes : 2 propriétés différentes ayant le même nom.
 Principe de non-redondance : chaque propriété doit apparaître une fois et une seule dans le
modèle.
Conception et modélisation d’un système d’information
15 Proposé par A BENDAOUD
Constitution du dictionnaire des données
Le dictionnaire des données est un document qui permet de recenser, de classer et de trier toutes les
informations (les données) collectées lors des entretiens ou de l’étude des documents. Le dictionnaire
peut être plus ou moins élaboré selon le niveau de granularité souhaité. En voici un exemple :
Cette étape consiste à référencer toutes les données du domaine. Pour notre service Achat, on peut
recenser un certain nombre d’éléments :
Nom de la donnée
Cette cellule recevra une donnée par exemple : Nom client.
Format
Ici sera indiqué le format de la donnée, par exemple : alphabétique.
Longueur
La longueur approximative ou exacte de la donnée sera indiquée, par exemple : 30.
Type
Une croix sera inscrite dans la colonne pour indiquer si la donnée est élémentaire ou calculée.
Règle de calcul
Ici sera indiquée de manière claire la formule ou le calcul nécessaire à appliquer pour obtenir la donnée.
Règle de gestion
Dans cette zone sera indiquée, si nécessaire, la règle de gestion inhérente à la donnée.
Document
La rubrique document permet de saisir le document dans lequel a été trouvée la donnée.
Voici ce que pourrait être le dictionnaire :
Conception et modélisation d’un système d’information
16 Proposé par A BENDAOUD
 Nom du fournisseur
 Date de la commande
 Numéro de la commande
 Quantité en stock de l’article
 Référence de l’article
 Prix unitaire de l’article
 Désignation de l’article
 Quantité commandée
 Condition de paiement
 Condition de livraison
 Téléphone du fournisseur
 Adresse du fournisseur
 Adresse de livraison
 Unité de l’article
 Taux de TVA
Chaque terme du dictionnaire des données est appelé Propriété. L’étape suivant consiste à
regrouper les propriétés dans des entités.
LES ENTITÉS
L’entité est la représentation d’un élément ayant un rôle dans le système. Une entité possède des
propriétés qui la décrivent. Un ensemble d’entités de même type s’appelle une classe d’entités.
Chaque entité est unique et est décrite par un ensemble de propriétés encore appelées attributs .
Une des propriétés de l'entité est l'identifiant. Cette propriété doit posséder des occurrences uniques
et doit être source des dépendances fonctionnelles avec toutes les autres propriétés de l'entité. Bien
souvent, on utilise une donnée de type entier qui s'incrémente pour chaque occurrence, ou encore
un code unique spécifique du contexte.
Le formalisme d'une entité est le suivant :
Conception et modélisation d’un système d’information
17 Proposé par A BENDAOUD
Ainsi, si on reprend notre dictionnaire de données précédent, on schématise par exemple une entité
«Auteur» comme ceci :
À partir de cette entité, on peut retrouver la règle de gestion suivante : un auteur est identifié par un
numéro unique (id_a) et est caractérisé par un nom, un prénom et une date de naissance.
Une entité peut avoir une ou plusieurs occurrences. Pour illustrer ce terme d'«occurrence» qui a déjà
été utilisé plusieurs fois, voici un exemple de table d'occurrences de l'entité Auteur :
id_a nom_a prenom_a date_naissance_a
1 Hugo Victor 1802-02-26
2 Rimbaud Arthur 1854-10-20
3 de Maupassant Guy 1850-08-05
Cette table est composée de trois occurrences de l'entité Auteur.
Remarques :
 Les occurrences sont parfois appelés tuples. Par ailleurs, la table d'occurrence peut être
comparée à l'instance d'une relation (implantation relationnelle d'une entité ou association)
à un moment donné. Nous reviendrons sur cette notion de relation dans la partie III.
 Au niveau conceptuel, on devrait plutôt parler d'entités-types , les entités étant en fait des instances
d'entités-types. Par soucis de simplicité, on gardera les termes d'entités et associations tout au long du
cours.
Dans notre cas, trois entités semblent se dégager :
 L’entité Fournisseur
 L’entité Article
 L’entité Commande
Conception et modélisation d’un système d’information
18 Proposé par A BENDAOUD
Une fois ces entités définies, on leur associe les propriétés du dictionnaire des données.
Un premier essai nous donne ceci :
Remarque
 Une propriété ne peut être dans plusieurs entités. Ici, par exemple, le prix d’un article est
une propriété de l’entité Article. Mais dans la mesure où ce prix est négocié en fonction de la
commande, il sera nécessaire de disposer de deux propriétés prix : une propriété Prix Article
dans l’entité Article et une propriété Prix Commande dans l’entité Commande.
Chaque fois qu’une propriété est associée à une entité on le signale dans le dictionnaire de
données.
 F Nom du fournisseur
 C Date de la commande
 C Numéro de la commande
 Quantité en stock de l’article
 A Référence de l’article
 A Prix unitaire de l’article
 A Désignation de l’article
 Quantité commandée
 Condition de paiement
 Condition de livraison
Conception et modélisation d’un système d’information
19 Proposé par A BENDAOUD
 F Téléphone du fournisseur
 F Adresse du fournisseur
 Adresse de livraison
 A Unité de l’article
 Taux de TVA
On se rend compte que certain éléments du dictionnaire de données ne figurent pas dans les
entités. Ceci peut être dû à plusieurs causes :
 Certains éléments ne sont pas des données. C’est peut être le cas des conditions de
paiement. En effet, ces conditions peuvent être le résultat d’un calcul dépendant de la
quantité commandée, du délai de livraison, …
 Certains éléments ne sont pas dans le domaine étudié. C’est le cas de la quantité en stock de
l’article. C’est bien une donnée mais cette donnée concerne la Gestion de stocks et non le
service Achat.
 Certains éléments sont peut-être des propriétés d’entités que l’on n’a pas encore créées ou
ils qualifient une relation entre entités. Par exemple la quantité commandée ne peut être
une propriété de l’entité Commande que si une commande ne fait l’objet que d’un seul
article, ce qui est un cas particulier.
IDENTIFIANT D’UNE ENTITE
Une entité est caractérisée par ses propriétés. Parmi ces propriétés il peut y avoir une,
plusieurs ou aucune permettant d’identifier une occurrence unique d’une entité. Si une telle
propriété existe, elle identifie l’entité. On la nomme identifiant.
L’identifiant sert à désigner, sans ambiguïté une occurrence de l’entité. Toute entité doit
avoir un identifiant.
La méthode Merise propose des représentations graphiques pour la plupart de notions
qu’elle utilise. Une entité est représentée par un rectangle dans lequel apparaissent son
nom et ses propriétés. Afin de faciliter la lecture des propriétés, le nom de l’identifiant est
souligné.
Exemple
 L’entité client a comme identifiant le numéro client.
 L’entité voiture ayant les propriétés : Numéro d’immatriculation, Couleur voiture, Marque a
comme identifiant la propriété Numéro d’immatriculation.
Conception et modélisation d’un système d’information
20 Proposé par A BENDAOUD
RELATIONS OU ASSOCIATION
Une association définit un lien sémantique entre une ou plusieurs entités. En effet, la définition de
liens entre entités permet de traduire une partie des règles de gestion qui n'ont pas été satisfaites
par la simple définition des entités.
Le formalisme d'une association est le suivant :
Généralement le nom de l'association est un verbe définissant le lien entre les entités qui sont reliées
par cette dernière. Par exemple :
Ici l'association «être né» traduit les deux règles de gestion suivantes :
 Un auteur est né dans un et un seul pays,
 Dans un pays, sont nés aucun, un ou plusieurs auteurs.
Vous remarquerez, que cette association est caractérisée par ces annotations 1,1 et 0,N
qui nous ont permis de définir les règles de gestions précédentes. Ces annotations sont appelées
les cardinalités.
Conception et modélisation d’un système d’information
21 Proposé par A BENDAOUD
Une relation ou association est un lien entre différentes entités. Ces liens se réalisent en se posant la
question : quelle entité interagit sur cette ou ces entités.
 Par exemple, un fournisseur fournit un article et un article est fourni par un fournisseur. En
effet il y a interaction entre les entités Fournisseur et Article que l’on traduit par l’action de
Fournir.
le prix peut être négocié faire les modifications nécessaires puis ajouter les cardinalités a cette
association :
 De même, une commande comporte des articles et les articles appartiennent à une
commande. La relation entre les entités Commande et Article est l’action de Commander
 Une relation peut avoir des propriétés. C’est le cas ici de la propriété Quantité qui est une
propriété de la relation Commander.
Fournisseur
Nom
Adresse
Téléphone
Article
Référence
Prix
Désignation
Unité
Fournir
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix Unitaire
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix cde.
Prix fnr.
0,n
0,n
1,n
1,n
Conception et modélisation d’un système d’information
22 Proposé par A BENDAOUD
 pour lever l’ambiguïté de la propriété Prix , la propriété Prix Unitaire est associée à l’entité
Article, la propriété Prix commande est associée à la relation Commander et la propriété Prix
fournisseur est associée à la relation Fournir.
C’est une relation qui liée une entité a elle-même :
Soit l’exemple suivant :
Ici l’entité employé joue deux rôles : rôle d’employé subordonné et rôle d’employé chef, on peut le
supposer comme si on a deux entité Employé superposées.
La patte de l’association du cardinalité 0,N part d’Employé qui a pour rôle Employé Chef
La patte de l’association du cardinalité 1,1 part d’Employé qui a pour rôle Employé subordonné
CARDINALITÉS
Relation réflexive
Employe
ID_Emp
nom
prenom
A pour chef
1,1
0,N
est chef de
Conception et modélisation d’un système d’information
23 Proposé par A BENDAOUD
Exemple :
Les valeurs 0,n 1,n 1,1 sont des cardinalités.
 La cardinalité 1,n de l’entité Commande pour la relation Commander signifie qu’une
commande peut avoir au moins un article et au plus N .
 La cardinalité 0,N de l’entité Article pour la relation Commander signifie qu’un Article peut ne
pas être commandé ou commandé plusieurs fois.
 La cardinalité 1,1 de l’entité commande pour la relation Passer signifie qu’une commande est
passée par un est un seul client minimum un client et maximum un client
 La cardinalité 1,N de l’entité client pour la relation Passer signifie qu’un client passe un ou
plusieurs commande
Il nous reste l’Adresse de livraison et le Taux de TVA.
 L’Adresse de livraison est une propriété de l’entité Commande.
Les cardinalités expriment le nombre minimum et maximum de fois qu’une entité est concernée
par la relation.
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix Unitaire
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix cde.
Prix fnr.
0,n
0,n
1,n
1,n
Client
Code
nom
prénom
Passer
1,N
1,1
Conception et modélisation d’un système d’information
24 Proposé par A BENDAOUD
 Pour le taux de TVA, il y a deux façons de résoudre le problème :
 Soit rattacher le taux à la relation Commander
Soit créer une entité Taux de TVA
Remarque
 On ne peut, dans l’état actuel de nos connaissance, définir qu’elle est la présentation la
mieux adaptée au problème. Il se peut de plus que la TVA soit fonction de la nature de
l’article et/ou du lieu de livraison (Export, Régime Intra/Extra Communautaire) .
 Un MCD ne peut être unique et varie nécessairement en fonction de règles de gestion et de
choix du concepteur.
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix moyen
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix comm.
Taux TVA
Prix four.
0,n
0,n
1,n
1,n
Fournisseur
Nom
Adresse
Téléphone Article
Référence
Prix moyen
Désignation
Unité
Fournir
Commande
Date
Numéro
Commander
Quantité
Prix comm.
Prix four.
0,n
0,n
1,n
1,n
Taux TVA
Code TVA
Taux TVA
0,n
Conception et modélisation d’un système d’information
25 Proposé par A BENDAOUD
 Une relation peut ne pas avoir de propriété
 Une relation peut être binaire, ternaire, …
L’IDENTIFIANT D’UNE ASSOCIATION
L'identifiant d'une association ayant des cardinalités 0,N/1,N de part et d'autre, est obtenu par la
concaténation des entités qui participent à l'association. Imaginons l'association suivante :
Ici un auteur rédige au moins un ou plusieurs livres et pour chaque livre, on connaît le nombre de
chapitres rédigés par l'auteur (on connaît aussi le nombre total de chapitres pour chaque livre).
L'association «rédiger» peut donc être identifiée par la concaténation des propriétés id_a et id_l.
Ainsi, le couple id_a, id_l doit être unique pour chaque occurrence de l'association. On peut
également définir la dépendance fonctionnelle suivante :
id_a, id_l → nb_chapitres
On dit que nb_chapitres (nombre de chapitres rédigés par un auteur, pour un livre) est une donnée
portée par l'association «rédiger». Cette association est donc une association porteuse de données.
Pour une association ayant au moins une cardinalité de type 0,1 ou 1,1 considérons dans un premier
temps que cette dernière ne peut être porteuse de données et qu'elle est identifiée par l'identifiant
de l'entité porteuse de la cardinalité 0,1 ou 1,1.
Nous reviendrons plus en détail sur la notion d'identification d'une association lors du passage au
modèle logique.
Conception et modélisation d’un système d’information
26 Proposé par A BENDAOUD
RELATION TERNAIRE
Une relation binaire est une relation qui lie deux entités
Une relation térnaire est une relation qui lie trois entités
On peut avoir des relations d’ordre N se sont des relations qui lient N entités
Exercice de réflexion :
Dans un cabinet médical les patients sont consultés par les médecins,un patient choisit le medecin
avec qui il va faire la consultation
Le premier modèle conceptuel relatif est :
Les informations concernant la relation « consulter » peuvent être représenté comme si on a une
entité qui a pour identifiant la concaténation des identifiants qui participent à la relation
« consulter » ;
Les entités qui participent à la relation sont médecin et patient d’où l’identifiant de la relation est
(codeM,codeP)
Toutefois les valeurs d’un identifiant sont unique c à d on ne peut pas avoir deux valeurs identiques
(a,b)<>(a’,b’)a<>a’ ou b<>b’
(a,b)=(a’,b’)a=a’ et b=b’
Medecin
codeM
nomM
telephoneM
Patient
codeP
nomP
telephoneP
consulter
dateConsultation
0,N
1,N
Fournir Commander
Quantité
Prix comm.
Prix four.
Relation binaire Relation ternaire
Conception et modélisation d’un système d’information
27 Proposé par A BENDAOUD
Cette premiére modélisation ne permet pas à un patient de faire plusieurs consultations par un
même médecin qui n’est pas logique.
M1 fait la consultation de p1 le 03/04/17 mais
M1 ne peut pas fait la consultation de p1 le 10/04/17 puisque l’identifiant de l’association est
(codeM,codeP).
Le triplet (M1,P1,03/04/17) est diffèrent du triplet(M1,P1,10/04/17),donc si on ajoute la date de
Consultation a l’identifiant de l’association consulter, le modèle peut supporter le cas « un patient
peut être consulté par plusieurs médecins a des dates différentes
D’où on aura le MCD suivant :
L’identifiant de l’association Visiter devient (codeM,codeP,dateVisite)
TRANSFORMATION D’UNE RELATION EN UNE ENTITÉ
En réalité dans une cabiné médicale quand un patient effectue une consultation, une fiche de
consultation va être remplit par les informations du patient et le numéro du médecin qui a fait la
consultation, puis le rapport des pathologies du patient.
D’où la relation consultation peut être remplacer par une entité « consultation » qui possède un
identifiant codec,et comme ça on se retrouve avec une modélisation qui représente fidèlement la
réalité
Medecin
codeM
nomM
telephoneM
Patient
codeP
nomP
telephoneP
consulter
dateConsulta
tion
0,N
1,N
date
datevisite
0,N
Conception et modélisation d’un système d’information
28 Proposé par A BENDAOUD
Medecin
codeM
nomM
telephoneM
Patient
codeP
nomP
telephoneP
passer
0,N 1,N
effectuer
consultation
codeC
dateC
1,1 1,1
Conception et modélisation d’un système d’information
29 Proposé par A BENDAOUD
Dépendance fonctionnelle
Notion de Dépendance Fonctionnelle
Formalisme :
A B : 1 source, 1 but
( A, B, …) X : plusieurs sources, 1 but
A ( X, Y, …) : 1 source , plusieurs buts
Exemples
N° Client Nom Client
Nom Client N° Client ( pas de DF)
Prénom Client N° Client ( pas de DF )
( Réf-prod , N° Commande ) Qté prod. commandée
Réf-prod ( Libellé prod. , Prix unit. Prod. )
DÉPENDANCE FONCTIONNELLE ÉLÉMENTAIRE
Définition : 2 propriétés A et B sont en DF si la connaissance d’une valeur de A détermine une et
une seule valeur de B . On dit que A détermine fonctionnellement B .
Une dépendance fonctionnelle A → B est élémentaire s’il n’existe pas une donnée C, sous
ensemble de A, décrivant une dépendance fonctionnelle de type C → B
Conception et modélisation d’un système d’information
30 Proposé par A BENDAOUD
Par exemple :
1- RéférenceProduit → Désignation
2- NuméroCommande, RéférenceProduit → Quantité
3- NuméroCommande, RéférenceProduit → Désignation
La première dépendance fonctionnelle est correcte car ayant une rubriques elle est élémentaire.
La deuxième dépendance fonctionnelle est correcte également car la connaissance d’un numéro de
commande et d’une référence produit nous permet de connaître la quantité commandé du produit.
Elle est aussi élémentaire car c’est la connaissance du couple (NuméroCommande, RéférenceProduit)
et pas seulement d’un des éléments qui permet la connaissance de la quantité.
La troisième dépendance fonctionnelle n’est pas élémentaire car il existe à l’intérieur d’elle
RéférenceProduit → Désignation
DÉPENDANCE FONCTIONNELLE ÉLÉMENTAIRE DIRECTE
Exemple :
NumClasse → NumElève
NumEleve → NomElève
NumClasse → NomElève
La troisième dépendance fonctionnelle n’est pas directe car nous pourrions écrire :
NumClasse → NumElève → NomElève
GRAPHE DE DÉPENDANCES FONCTIONNELLES
GDF = Représentation graphique de l’ensemble des DFs unissant les propriétés dans un domaine
d’activité du système d’information. Ces propriétés sont obtenues à partir du dictionnaire de
données du domaine.
Exemple : GDF du domaine « Gestion commerciale » dans une entreprise
On dit que la dépendance fonctionnelle A → B est directe s’il n’existe aucun attribut C tel que l’on
puisse avoir A → C et C → B. En d’autres termes, cela signifie que la dépendance fonctionnelle
entre A et B ne peut pas être obtenue par transitivité.
Conception et modélisation d’un système d’information
31 Proposé par A BENDAOUD
PERSONNALISATION D’ASSOCIATIONS
BUT : Transformer une association en entité lorsqu’il y a une perte sémantique dans le MCD par
rapport aux règles de gestion du S.I
0,N
Client
N client
Nom Client
Adresse Client
Voiture
Matricule
marque
chevaux
ASSUREURE
N Assureur
Nom Assureur
Adresse Assureur
Assurer
dateSignature
date echeance
montant
prime
1,N
0,N
Conception et modélisation d’un système d’information
32 Proposé par A BENDAOUD
Selon le modèle, le client ne peut signer qu’un seul contrat d’assurance pour un véhicule donné avec
le même assureur d’après la structure de l’identifiant de l’association.
Solution : Personnaliser l’association « Assurer » en entité
D’où maintenant
Un client peut signer plusieurs contrats d’assurance relatifs au même véhicule chez le même
assureur.
1 ,1
ASSUREURE
N Assureur
Nom Assureur
Adresse Assureur
Client
N client
Nom Client
Adresse Client
Voiture
Matricule
marque
chevauxCONTRAT
N Contrat
Date signature
Date écheance
Montant
Prime
CIF
CIF
CIF
1,N
1,N
1,N
1,11,1
1,1
Conception et modélisation d’un système d’information
33 Proposé par A BENDAOUD
DÉPENDANCES FONCTIONNELLES PARTICULIÈRES ET REPRÉSENTATIONS MERISE 2
Conception et modélisation d’un système d’information
34 Proposé par A BENDAOUD
Les formes normales
INTRODUCTION
Nous allons aborder dans ce document les principes de normalisation des données. Nous parlerons
de modèles de données conforment à la 1ère
, 2ème
ou 3ème
forme normale.
Dans une base de données relationnelle, une forme normale désigne un type de relation particulier
entre les entités. Comme son nom l’indique, normale décrit la norme.
La normalisation s’applique à toutes les entités et aux relations porteuses de propriétés.
On dira d’un modèle qu’il est en première, deuxième ou troisième forme normale. Il s’agit là des
règles de normalisation les plus importantes, d’autres règles pouvant être appliquées mais de
manière non systématique.
La forme normale vient après la simple validité d'un modèle relationnel, c'est-à-dire que les valeurs
des différents attributs soient bien en dépendance fonctionnelle avec la clé primaire (complètement
déterminés par la clé primaire).
En pratique, la première et la deuxième forme normale sont nécessaires pour avoir un modèle
relationnel juste. Les formes normales supplémentaires ont leurs avantages et leurs inconvénients.
Definition
La normalisation des modèles de données permettra donc de s’assurer de la robustesse de la
conception de la base pour améliorer la modélisation (et donc obtenir une meilleure
représentation) et optimiser la mémorisation des données en évitant la redondance et les
problèmes sous-jacents de mise à jour ou de cohérence.
Conception et modélisation d’un système d’information
35 Proposé par A BENDAOUD
Les avantages sont :
 de limiter les redondances de données
 de limiter les incohérences de données qui pourraient les rendre inutilisables
 d'éviter les processus de mise à jour récurrents
Les inconvénients sont :
 des temps d'accès qui peuvent être plus longs si les requêtes sont trop complexes
 un manque de flexibilité au niveau de l'utilisation de l'espace de stockage
La troisième forme normale reste généralement une des meilleures solutions d'un point de vue
architecture de base de données, mais pour des bases de données plus importantes, cela n'est pas
toujours le cas. Il s'agit de choisir l'équilibre entre deux options :
 la génération dynamique des données via les jointures entre tables
 l'utilisation statiques de données correctement mises à jour
 La normalisation des modèles de données a été popularisée principalement par la méthode
Merise. La principale limite de la normalisation est que les données doivent se trouver dans
une même base de données (dans un seul schéma).
Avantages et inconvénients
Conception et modélisation d’un système d’information
36 Proposé par A BENDAOUD
Exemple
 client (code Cl, nom&prenom, age)
n’est pas en 1FN car nom&prenom n’est pas atomique on eclate la propriété nom&prenom
client (code Cl, nom,prenom, age)
client n’est en 1FN car âge n’est pas constant dans le temps
client (code Cl, nom,prenom,dateNaissance)
 Article(ref,designation,codeCategorie) n’est pas en 1FN car codeCategorie est répétitive
d’où on crée une entité categorie
 Notée 2FN - deuxième forme normale
La première forme normale :
Notée 1FN - première forme normale : Respecte la première forme normale, la relation dont tous
les attributs :
1- contiennent une valeur atomique. Ainsi, le nom et le prénom d’une personne doivent être dans
des propriétés distinctes.
2-contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans un seul
attribut). On pourrait citer pour exemple une catégorie d’articles qui doit être définie dans une
entité spécifique et non répétée dans l’entité article.
3-sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge).
La deuxième forme normale
Respecte la seconde forme normale, la relation respectant la première forme normale et dont :
Tous les attributs non-clés ne dépendent pas d'une partie de la clé primaire mais bien de la totalité
de la clé primaire.
Article
Ref
designation
Categorie
codeCategorie
nomCategorie
Appartient
1,1 0,N
Conception et modélisation d’un système d’information
37 Proposé par A BENDAOUD
 Le non-respect de la 2FN entraine une redondance des données qui encombrent alors
inutilement la mémoire et l'espace disque.
Autrement dit et exemple!!
 Une relation est dite en deuxième forme normale si elle est en première forme normale, et
si tout attribut n'appartenant pas à la clé primaire ne dépend pas d'une partie de cette clé.
EXEMPLE
Conception et modélisation d’un système d’information
38 Proposé par A BENDAOUD
LA TROISIÈME FORME NORMALE
 Notée 3FN - troisième forme normale
Autrement dit et exemple!!
 Une relation est dite en troisième forme normale si elle est en deuxième forme normale, et
si toutes les dépendances fonctionnelles issues de la clé primaire sont directes.
Exemple1
 R-MATERIEL (code matériel, libellé matériel, code marque, libellé marque)
 La dépendance entre "code matériel" et "libellé marque" n'est pas directe, "libellé marque"
est en dépendance fonctionnelle directe avec le "code marque".
code matériel code marque libellé marque
 La relation doit être éclatée en deux, pour être exprimée en troisième forme normale :
Respecte la troisième forme normale, la relation respectant la seconde forme normale et doit avoir
tous les attributs n'appartenant pas à la clé ne dépendent pas d'un attribut non-clé. En d'autre
terme, la dépendance fonctionnelle est directe.
Conception et modélisation d’un système d’information
39 Proposé par A BENDAOUD
Le Modèle logique de données
INTRODUCTION
Le MCD est une représentation du réel tel qu’il est perçu par l’utilisateur. Ce modèle, en tant
que formalisme (définir les entités, les associations et les propriétés et leur enchaînement
chronologique et fonctionnel) est commandé par l’utilisateur et donc, n’est pas remis en
cause par un changement de matériel ou de logiciel ou par des changements issus des
contraintes organisationnelles.
 De ce point de vue, le MCD constitue, dans l’ensemble des modèles proposés par la méthode
Merise, le modèle le plus stable.
PROBLÉMATIQUE :
 Toutefois le MCD reste un modèle abstrait. Les concepts (leurs définitions et leurs
comportements) ne sont pas représentés d’une manière qui pourrait conduire à un
traitement informatique facile et rapide.
 D’où la nécessité d’une étape intermédiaire - modèle logique des données (MLD) - proposant
une représentation de données en vue de leur traitement par ordinateur.
TRANSFORMATION D’UN INDIVIDU OU ENTITÉ TYPE
 Toute entité devient une table. Ses propriétés deviennent des attributs de la table (colonne).
 L’identifiant devient la clé primaire unique de la table.
R-MATERIEL
codemateriel
libellé materiel
R-marque
codemarque
libellé marque
Appartient
1,1 0,N
Conception et modélisation d’un système d’information
40 Proposé par A BENDAOUD
TRANSFORMATION D’UNE RELATION BINAIRE (0,N)-(1,1) OU (1,N)-(1,1)
 On duplique la clé issue de l’identifiant de l’individu porteur de la cardinalité (0,n) ou (1,n)
dans la table issue de l’individu à cardinalité (1,1).Celle-ci devient alors une clé étrangère.
 L’entité B est une entité source (ou entité père). L’entité A est une entité cible (ou entité
fils). La transformation se fait selon le principe : le père donne son nom à son fils.
Le fils attire le père
 Donc, l’entité père (l’entité B) donne son identifiant à l’entité fils (l’entité A).
Exemple :
Un Employé utilise un est un seul Ordinateur
un ordinateur est utilisé par plusieurs Employés
MAISON
IdMaison
Date Construction
Surface
MAISON
IdMaison
DateConstruction
Surface
entité table
1 ,1
Conception et modélisation d’un système d’information
41 Proposé par A BENDAOUD
SOLUTION
MCD
MLD
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
Possede
DateP
0,n
1,1
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
#Code
DateP
ORDINATEUR
Num
type
Modele
Employe
Code
nom
prenom
1,N
1,1
Conception et modélisation d’un système d’information
42 Proposé par A BENDAOUD
TRANSFORMATION D’UNE RELATION BINAIRE (0,N)-(0,1) OU (1,N)-(0,1)
Deux solutions :
 Création d’une table avec comme clé primaire l’identifiant de l’individu porteur de la
cardinalité (0,1) et comme clé étrangère l’identifiant de l’individu porteur de la cardinalité
(*, n).
 Duplication de l’identifiant de l’individu porteur de la cardinalité (*, n) dans la table issue de
l’individu porteur de la cardinalité (0,1) qui devient alors une clé étrangère. Il faut pour cette
deuxième solution que le SGBD cible accepte des valeurs nulles pour la clé étrangère.
Le fils attire le père
Exemple :
Remarque l’association Possède contient la propriété DateP
Solution 1
0,n
0,1
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
Possede
DateP
Conception et modélisation d’un système d’information
43 Proposé par A BENDAOUD
Solution 2 :
TRANSFORMATION D’UNE RELATION BINAIRE (0,1)-(1,1)
La clé issue de l’identifiant de l’entité porteuse de la cardinalité (0,1) est dupliquée dans la
table issue de l’entité porteuse de la cardinalité (1,1) et devient une clé étrangère.
L’association Parrain est une association porteuse car elle contient la propriétés DateP
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
Possede
IdMaison
Code
DateP
Personne
Code
Nom
prenom
Maison
IdMaison
DateConstruction
Surface
#Code
DateP
Contact
IdContact
Nom
prenom
Stagiaire
IdStagiaire
DateNaissance
#IdContact
DateP
0 ,1 1,1Parrain
dateP
Contact
IdContact
Nom
prenom
Stagiaire
IdStagiaire
DateNaissance
Conception et modélisation d’un système d’information
44 Proposé par A BENDAOUD
TRANSFORMATION D’UNE RELATION BINAIRE (0,1)-(0,1)
 C’est une particularisation des cas précédemment traités. 2 types de solutions sont possibles
Les solutions
Type de solution : Créer une table avec comme attributs les identifiants des individus en relation et
comme clé primaire l’un des identifiants d’une des deux tables. Les deux attributs sont des clés
étrangères.
1,1
Correspond
0,1
ENTREPRISE
IDEntreprise
Raison Sociale
…
TIERS
IdTiers
…
0,1
Conception et modélisation d’un système d’information
45 Proposé par A BENDAOUD
Exemple de schémas relationnels :
 Table ENTREPRISE(IDEntreprise, RaisonSociale,…)
 Table TIERS (IdTiers,…)
 Table CORRESPOND (Idtiers, IDEntreprise) ou table CORRESPOND(IdTiers, IDEntreprise)
2 type de solution : Duplication de la clé d’une des deux tables issues des entités types dans l’autre
table.
 Table ENTREPRISE (IDEntreprise,RaisonSociale,…,IDtiers)
 Table TIERS (IdTiers,…)
OU
 Table ENTREPRISE (IDEntreprise,RaisonSociale,…)
 Table TIERS (IdTiers,…,IDEntreprise)
TRANSFORMATION D’UNE RELATION BINAIRE (*,N)-(*,N)
 La table LOUER aura comme schéma relationnel LOUER (Code, IDMaison, DateEntree)
l’association Louer est une association porteuse car elle contient la propriétés DateEntree
solution :
La solution consiste à créer une table dont la clé sera une clé composée des identifiants des deux
entités en relation. Les propriétés éventuelles de la relation seront des attributs de la table.
Personne
Code
Nom
Prenom
Maison
IDmaison
Numero
rue
codePostal
Louer
dateEntree
0,n 0,n
Conception et modélisation d’un système d’information
46 Proposé par A BENDAOUD
TRANSFORMATION D’UNE RELATION TERNAIRE ET SUPÉRIEURE QUELLES QUE SOIT LES
CARDINALITÉS
 La relation donne lieu à la création d’une table qui aura comme clé primaire une clé
composée des identifiants des individus sur lesquels portent la relation.
MAISON
IdMaison
DateConstruction
Surface
ENTREPRISE
IdEntreprise
Raison Sociale
…
TYPE TRAVAUX
IdTypeTravail
Désignation Travail
…
Réaliser
Date Réalisation
*,n *,n
*,n
Conception et modélisation d’un système d’information
47 Proposé par A BENDAOUD
 La table REALISER aura comme schéma relationnel
 REALISER (IdEntreprise, IDMaison, IdTypeTravail, DateRealisation)
Application
 Trouvez le modèle logique de données
Solution :
Conception et modélisation d’un système d’information
48 Proposé par A BENDAOUD
Application 2
Solution :
Conception et modélisation d’un système d’information
49 Proposé par A BENDAOUD
Application 3
Solution :
Conception et modélisation d’un système d’information
50 Proposé par A BENDAOUD
Application 4
APPLICATION DES RÈGLES DE PASSAGE SUR UNE RELATION RÉFLEXIVE
Soit l’exemple suivant
Le Modèle logique équivalent est :
Avion
numV
marque
nbplaces
vol
numVo
DateVo
ville
numV
nomV
Utilise
Escale
Départ
Arrivé
1,N 1,1
1,1
1,1
0,N
0,N
0,N
0,N
Employe
ID_Emp
nom
prenom
Est chef de A pour chef
1,1
0,N
Employe
ID_Emp
nom
prenom
#ID_EmpChef
Conception et modélisation d’un système d’information
51 Proposé par A BENDAOUD
Exemple 2
Le Modèle logique équivalent est :
APPLICATION DES RÈGLES DE PASSAGE SUR UNE ENTITÉ FAIBLE
Exemple1 :
On a un hôtel qui est constitué de plusieurs étages, les chambres sont numérotées de 1 à 10 sur
chaque étage.
Etage4 1 2 3 4 5 6 7 8 9 10
Etage 3 1 2 3 4 5 6 7 8 9 10
Etage2 1 2 3 4 5 6 7 8 9 10
Etage1 1 2 3 4 5 6 7 8 9 10
Ici l’entité chambre est une entité faible car NumCh tout seul ne peut pas definir une chambre, une
chambre est bien défini si on spécifie l’etage, d’où NumEt,NumCh une chambre,une entité faible
est représenté par (1,1)
D’où le modèle logique équivalent est :
Article
Ref
Designation
Prix
Composition
Qtite
0,N
0,N
Article
Ref
Designation
Prix
Composition
Ref
Ref Composant
Qtite
Hotel
NumHo
Adresse
Etage
NumEt
Chambre
NumChAppartient
Appartient
1,N
1,1
1,N
(1,1)
Conception et modélisation d’un système d’information
52 Proposé par A BENDAOUD
Remarque : NumEt est dupliqué sur la table Chambre autant que clé étrangère et clé primaire car
chambre est une entité faible.
Exemple 2
D’où le modèle logique équivalent est :
Hotel
NumHo
Adresse
Etage
NumEt
#NumHo
Chambre
NumCh
#NumEt
jour
NumJ
NomJ
semaine
NumS
Annee
Annee
Appartient
(1,1) 1,N
Appartient
(1,1) 1,N
jour
NumJ
NumS
Annee
NomJ
semaine
NumS
Annee
Annee
Annee

Contenu connexe

Tendances

T1 corrections-qcm
T1 corrections-qcmT1 corrections-qcm
T1 corrections-qcminfcom
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
Ilyas CHAOUA
 
Introduction à l'informatique
Introduction à l'informatiqueIntroduction à l'informatique
Introduction à l'informatique
lmodadam
 
Tp n 3 linux
Tp n 3 linuxTp n 3 linux
Tp n 3 linux
Amir Souissi
 
Etude de la virtualisation
Etude de la virtualisationEtude de la virtualisation
Etude de la virtualisation
Antoine Benkemoun
 
Examen 2011 exo 4
Examen 2011 exo 4Examen 2011 exo 4
Examen 2011 exo 4
cheikhany ejiwen
 
Conception et développement d’un système d’alerte et notification d’une tou...
Conception et développement  d’un système d’alerte et notification  d’une tou...Conception et développement  d’un système d’alerte et notification  d’une tou...
Conception et développement d’un système d’alerte et notification d’une tou...
Bilel Khaled ☁
 
Servlets et JSP
Servlets et JSPServlets et JSP
Servlets et JSP
Heithem Abbes
 
Gestion des threads
Gestion des threadsGestion des threads
Gestion des threads
Sana Aroussi
 
Support du cours : Systèmes d'exploitation 2 (linux)
Support du cours : Systèmes d'exploitation 2 (linux)Support du cours : Systèmes d'exploitation 2 (linux)
Support du cours : Systèmes d'exploitation 2 (linux)
Faycel Chaoua
 
Support JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.YoussfiSupport JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.Youssfi
ENSET, Université Hassan II Casablanca
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5
YounessLaaouane
 
applications-reparties
applications-repartiesapplications-reparties
applications-reparties
mourad50
 
Support de cours Spring M.youssfi
Support de cours Spring  M.youssfiSupport de cours Spring  M.youssfi
Support de cours Spring M.youssfi
ENSET, Université Hassan II Casablanca
 
cloud.pdf
cloud.pdfcloud.pdf
cloud.pdf
hasna920888
 
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Gedeon AGOTSI
 
diagramme des cas d'utilisation
diagramme des cas d'utilisationdiagramme des cas d'utilisation
diagramme des cas d'utilisation
Amir Souissi
 
QCM Sécurité Informatique
QCM Sécurité InformatiqueQCM Sécurité Informatique
QCM Sécurité Informatique
Zakariyaa AIT ELMOUDEN
 
Corrige tp java
Corrige tp javaCorrige tp java
Corrige tp java
Maya Medjdoub
 

Tendances (20)

T1 corrections-qcm
T1 corrections-qcmT1 corrections-qcm
T1 corrections-qcm
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Introduction à l'informatique
Introduction à l'informatiqueIntroduction à l'informatique
Introduction à l'informatique
 
Tp n 3 linux
Tp n 3 linuxTp n 3 linux
Tp n 3 linux
 
Etude de la virtualisation
Etude de la virtualisationEtude de la virtualisation
Etude de la virtualisation
 
Examen 2011 exo 4
Examen 2011 exo 4Examen 2011 exo 4
Examen 2011 exo 4
 
Conception et développement d’un système d’alerte et notification d’une tou...
Conception et développement  d’un système d’alerte et notification  d’une tou...Conception et développement  d’un système d’alerte et notification  d’une tou...
Conception et développement d’un système d’alerte et notification d’une tou...
 
Servlets et JSP
Servlets et JSPServlets et JSP
Servlets et JSP
 
Gestion des threads
Gestion des threadsGestion des threads
Gestion des threads
 
Support du cours : Systèmes d'exploitation 2 (linux)
Support du cours : Systèmes d'exploitation 2 (linux)Support du cours : Systèmes d'exploitation 2 (linux)
Support du cours : Systèmes d'exploitation 2 (linux)
 
Support JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.YoussfiSupport JEE Servlet Jsp MVC M.Youssfi
Support JEE Servlet Jsp MVC M.Youssfi
 
Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5Rapport de stage Application web Gestion RH ASP.NET MVC5
Rapport de stage Application web Gestion RH ASP.NET MVC5
 
applications-reparties
applications-repartiesapplications-reparties
applications-reparties
 
Support de cours Spring M.youssfi
Support de cours Spring  M.youssfiSupport de cours Spring  M.youssfi
Support de cours Spring M.youssfi
 
cloud.pdf
cloud.pdfcloud.pdf
cloud.pdf
 
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
Mémoire de fin de formation pour l'obtention du diplome d'ingénieur des trava...
 
diagramme des cas d'utilisation
diagramme des cas d'utilisationdiagramme des cas d'utilisation
diagramme des cas d'utilisation
 
QCM Sécurité Informatique
QCM Sécurité InformatiqueQCM Sécurité Informatique
QCM Sécurité Informatique
 
Corrige tp java
Corrige tp javaCorrige tp java
Corrige tp java
 

Similaire à Mon cours merise v2017

Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
Com'3elles - www.com3elles.com
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
Codendi
 
Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0ACDISIC
 
Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
Céline Robert
 
Livre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veilleLivre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veilleAref Jdey
 
Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011
Digimind
 
Ovidentia Guide Utilisateur
Ovidentia Guide UtilisateurOvidentia Guide Utilisateur
Ovidentia Guide Utilisateur
guest5fb52b
 
Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013
UGAIA
 
Technocles2010 1
Technocles2010 1Technocles2010 1
Technocles2010 1
Cyril Durand
 
Livre blanc de J2ME
Livre blanc de J2MELivre blanc de J2ME
Livre blanc de J2ME
Bruno Delb
 
Guide administrateur rubedo 3x
Guide administrateur rubedo 3xGuide administrateur rubedo 3x
Guide administrateur rubedo 3x
Rubedo, a WebTales solution
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
Digimind
 
Course outline p6
Course outline p6Course outline p6
Course outline p6Kazim Naqvi
 
Modelisation orientee objet
Modelisation orientee objetModelisation orientee objet
Modelisation orientee objet
Zakaria Boulouard
 
INFORMATIQUE DES GESTION : MERISE
INFORMATIQUE DES GESTION : MERISE INFORMATIQUE DES GESTION : MERISE
INFORMATIQUE DES GESTION : MERISE HINDOUSSATI
 
Mémoire seo-fb
Mémoire seo-fbMémoire seo-fb
Mémoire seo-fb
Fanny_Bardel
 
dede
dededede
dede
zaiim
 
ututu
ututuututu
ututu
zaiim
 

Similaire à Mon cours merise v2017 (20)

Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
 
Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0
 
Administration joomla2 5
Administration joomla2 5Administration joomla2 5
Administration joomla2 5
 
19
1919
19
 
Livre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veilleLivre blanc : nouveaux usages de la veille
Livre blanc : nouveaux usages de la veille
 
Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011Digimind: Benchmark Solutions de Veille 2011
Digimind: Benchmark Solutions de Veille 2011
 
Ovidentia Guide Utilisateur
Ovidentia Guide UtilisateurOvidentia Guide Utilisateur
Ovidentia Guide Utilisateur
 
Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013Configuration vm sur hyper sharepoint 2013
Configuration vm sur hyper sharepoint 2013
 
Technocles2010 1
Technocles2010 1Technocles2010 1
Technocles2010 1
 
Livre blanc de J2ME
Livre blanc de J2MELivre blanc de J2ME
Livre blanc de J2ME
 
Guide administrateur rubedo 3x
Guide administrateur rubedo 3xGuide administrateur rubedo 3x
Guide administrateur rubedo 3x
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
 
Course outline p6
Course outline p6Course outline p6
Course outline p6
 
Modelisation orientee objet
Modelisation orientee objetModelisation orientee objet
Modelisation orientee objet
 
INFORMATIQUE DES GESTION : MERISE
INFORMATIQUE DES GESTION : MERISE INFORMATIQUE DES GESTION : MERISE
INFORMATIQUE DES GESTION : MERISE
 
Mémoire seo-fb
Mémoire seo-fbMémoire seo-fb
Mémoire seo-fb
 
Guide administrateur22
Guide administrateur22Guide administrateur22
Guide administrateur22
 
dede
dededede
dede
 
ututu
ututuututu
ututu
 

Dernier

Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La JeunesseConseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Oscar Smith
 
Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024
Friends of African Village Libraries
 
Iris van Herpen. pptx
Iris            van        Herpen.     pptxIris            van        Herpen.     pptx
Iris van Herpen. pptx
Txaruka
 
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
cristionobedi
 
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
mrelmejri
 
Iris van Herpen. pptx
Iris         van        Herpen.      pptxIris         van        Herpen.      pptx
Iris van Herpen. pptx
Txaruka
 
Procédure consignation Lock Out Tag Out.pptx
Procédure consignation  Lock Out Tag Out.pptxProcédure consignation  Lock Out Tag Out.pptx
Procédure consignation Lock Out Tag Out.pptx
caggoune66
 
Cycle de Formation Théâtrale 2024 / 2025
Cycle de Formation Théâtrale 2024 / 2025Cycle de Formation Théâtrale 2024 / 2025
Cycle de Formation Théâtrale 2024 / 2025
Billy DEYLORD
 
Edito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdfEdito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdf
WarlockeTamagafk
 
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
BenotGeorges3
 
Iris van Herpen. pptx
Iris         van         Herpen.      pptxIris         van         Herpen.      pptx
Iris van Herpen. pptx
Txaruka
 
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
M2i Formation
 

Dernier (12)

Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La JeunesseConseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
Conseils pour Les Jeunes | Conseils de La Vie| Conseil de La Jeunesse
 
Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024Burkina Faso library newsletter May 2024
Burkina Faso library newsletter May 2024
 
Iris van Herpen. pptx
Iris            van        Herpen.     pptxIris            van        Herpen.     pptx
Iris van Herpen. pptx
 
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
Formation Intelligence Artificielle pour dirigeants- IT6-DIGITALIX 24_opt OK_...
 
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
Impact des Critères Environnementaux, Sociaux et de Gouvernance (ESG) sur les...
 
Iris van Herpen. pptx
Iris         van        Herpen.      pptxIris         van        Herpen.      pptx
Iris van Herpen. pptx
 
Procédure consignation Lock Out Tag Out.pptx
Procédure consignation  Lock Out Tag Out.pptxProcédure consignation  Lock Out Tag Out.pptx
Procédure consignation Lock Out Tag Out.pptx
 
Cycle de Formation Théâtrale 2024 / 2025
Cycle de Formation Théâtrale 2024 / 2025Cycle de Formation Théâtrale 2024 / 2025
Cycle de Formation Théâtrale 2024 / 2025
 
Edito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdfEdito-B1-francais Manuel to learning.pdf
Edito-B1-francais Manuel to learning.pdf
 
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
Newsletter SPW Agriculture en province du Luxembourg du 12-06-24
 
Iris van Herpen. pptx
Iris         van         Herpen.      pptxIris         van         Herpen.      pptx
Iris van Herpen. pptx
 
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
Formation M2i - Onboarding réussi - les clés pour intégrer efficacement vos n...
 

Mon cours merise v2017

  • 1. Conception et modélisation d’un système d’information 1 Proposé par A BENDAOUD OFPPT/DRPS/ISGI LAAYOUNE MODULE : Conception et modélisation d'un système d'information FILIERE : TECHNIQUES DE DEVELOPPEMENT INFORMATIQUE Proposé par : FORMATEUR A BENDAOUD
  • 2. Conception et modélisation d’un système d’information 2 Proposé par A BENDAOUD Sommaire La conception d’un système d’information............................................................................................. 4 Plan...................................................................................................................................................... 4 Histoire ................................................................................................................................................ 4 Causes d’échec .................................................................................................................................... 4 Introduction......................................................................................................................................... 5 Merise???............................................................................................................................................ 5 Notion de système d’information de l’entreprise............................................................................... 5 Architecture et fonctionnement d’un système d’information............................................................ 6 Fonctionnement d’un système d’information .................................................................................... 6 Système d’information et système informatique ............................................................................... 6 Les trois cycles de Merise.................................................................................................................... 7 Cycle de vie en cascade................................................................................................................... 7 Étude préalable par domaine :........................................................................................................ 8 Étude détaillée par projet :................................................................................................................ 8 Cycle de vie en spirale ..................................................................................................................... 9 Courbe du soleil............................................................................................................................... 9 Les systèmes informatiques ............................................................................................................. 10 Résumé.......................................................................................................................................... 10 Cycles d’abstraction de conception des S.I ....................................................................................... 11 Modèle conceptuel des données .......................................................................................................... 12 Introduction au Modèle Conceptuel des Données ........................................................................... 12 La séparation des données et des traitements................................................................................. 12 1. Les données (ou informations)...................................................................................................... 12 a. L’interview ................................................................................................................................. 12 b. L’étude des documents internes............................................................................................... 13 c. L’étude des documents externes............................................................................................... 13 Les différents types d’informations .................................................................................................. 13 a.Les informations élémentaires et mémorisables....................................................................... 13 b. Les informations calculées ........................................................................................................ 13 c. Les traitements .......................................................................................................................... 13 Propriété (ou attribut)....................................................................................................................... 14
  • 3. Conception et modélisation d’un système d’information 3 Proposé par A BENDAOUD Constitution du dictionnaire des données............................................................................................ 15 Les entités.......................................................................................................................................... 16 Identifiant d’une entite ..................................................................................................................... 19 Relations ou Association ................................................................................................................... 20 Relation réflexive........................................................................................................................... 22 Cardinalités........................................................................................................................................ 22 L’identifiant d’une association .......................................................................................................... 25 Relation ternaire................................................................................................................................ 26 Transformation d’une relation en une entité ................................................................................... 27 Notion de Dépendance Fonctionnelle................................................................................................... 29 Dépendance fonctionnelle élémentaire............................................................................................ 29 Dépendance fonctionnelle élémentaire directe............................................................................. 30 Graphe de Dépendances Fonctionnelles........................................................................................... 30 PERSONNALISATION D’ASSOCIATIONS ............................................................................................. 31 Dépendances Fonctionnelles particulières et Représentations MERISE 2....................................... 33 Les formes normales ............................................................................................................................. 34 Introduction....................................................................................................................................... 34 Definition....................................................................................................................................... 34 Avantages et inconvénients .......................................................................................................... 35 La première forme normale : ........................................................................................................ 36 La deuxième forme normale ......................................................................................................... 36 La troisième forme normale.............................................................................................................. 38 Le Modèle logique de données ............................................................................................................. 39 Introduction....................................................................................................................................... 39 Problématique :................................................................................................................................. 39 Transformation d’un individu ou entité type.................................................................................... 39 Transformation d’une relation binaire (0,n)-(1,1) ou (1,n)-(1,1)....................................................... 40 Transformation d’une relation binaire (0,n)-(0,1) ou (1,n)-(0,1)....................................................... 42 Transformation d’une relation binaire (0,1)-(1,1)............................................................................. 43 Transformation d’une relation binaire (0,1)-(0,1)............................................................................. 44 Transformation d’une relation binaire (*,n)-(*,n)............................................................................. 45 Transformation d’une relation ternaire et supérieure quelles que soit les cardinalités .................. 46 Application des règles de passage sur une relation réflexive ........................................................... 50 Application des règles de passage sur une entité faible................................................................... 51
  • 4. Conception et modélisation d’un système d’information 4 Proposé par A BENDAOUD La conception d’un système d’information PLAN  Introduction  Merise??  Notion de système d’information de l’entreprise  Architecture et fonctionnement d’un système d’information  Système d’information et système informatique  Les trois cycles de Merise HISTOIRE Il y ’a maintenant cinq siècles, Cristoforo Colombo, aventurier d’origine génoise, persuadé de la rotondité de notre planète, élabora le projet déconcertant d’atteindre les Indes par voie maritime, en se dirigeant vers l ’Ouest.. L ’Histoire nous enseigne qu’il n ’atteignit jamais cet objectif, mais découvrit à la place les Amériques, la terre nouvelle!!!§ CAUSES D’ÉCHEC 1. Méconnaissance quasiment totale du sujet sur ces principaux aspects, les Indes et l ’Océan. 2. Incapacité à estimer la durée et les charges de la traversée (Conséquence directe de 1) 3. Inadaptation flagrante du système de contrôle. 4. Incapacité à maintenir la cohésion de l’équipage 5. C’est de croire qu’il n’y a que 4 causes d'échec d’un projet
  • 5. Conception et modélisation d’un système d’information 5 Proposé par A BENDAOUD INTRODUCTION  La conception d’un système d’information n’est pas chose aisée puisqu’il faut réfléchir à l’ensemble de l’organisation qui doit être mise en place. Pour y arriver, il est nécessaire de concevoir des méthodes pour l’élaboration d’un modèle du S.I. On parle ainsi de modélisation ou de représentation virtuelle de la réalité. Ce type de méthodes est appelé Analyse. Il existe plusieurs méthodes d’analyse, une des plus connues est la méthode MERISE. MERISE???  MERISE est une méthode qui permet l’élaboration d’un système d’information. Cette méthode est basée sur un concept fondamental : la séparation des données et des traitements, cela est motivé par le fait que les données ne sont changées que rarement, par contre, les traitements le sont plus souvent (contrairement à des pratiques plus récentes de modélisation orientée objet où l’on ne sépare plus les données et les traitements).  La méthode MERISE a vu le jour en 1978, et elle a été mise au point par 2 sociétés françaises : le CTI (Centre Technique d’Informatique) et le CETE (Centre d’Études Techniques de l’Équipement). NOTION DE SYSTÈME D’INFORMATION DE L’ENTREPRISE  L’entreprise est un système complexe dans lequel transitent de nombreux flux d’informations. L’objectif de la mise en place d’un S.I est de maîtriser ces flux par la collecte, la mémorisation, la distribution de l’information (avec un temps de réponse rapide). Ce S.I assurera le lien entre 2 autres systèmes de l’entreprise : le système opérant et le système de pilotage. Système de Pilotage Système opérant Système D’information
  • 6. Conception et modélisation d’un système d’information 6 Proposé par A BENDAOUD Le système de pilotage décide des actions à conduire sur le système opérant en fonction des objectifs et des politiques de l’entreprise. Le système opérant comprend toutes les fonctions liées à l’activité propre de l’entreprise : facturer les clients, payer les salariés, gérer les stocks… ARCHITECTURE ET FONCTIONNEMENT D’UN SYSTÈME D’INFORMATION  Le S.I doit décrire (ou représenter) le plus fidèlement possible le fonctionnement du système opérant. Pour cela, il doit intégrer une base d’information dans laquelle sont mémorisées : la description des objets, des règles et contraintes du système opérant.  Cette base doit évoluer, c’est pourquoi le S.I contient « le processeur d’information » ayant pour but de piloter et contrôler les changements de la base. FONCTIONNEMENT D’UN SYSTÈME D’INFORMATION  Voici le schéma de l’architecture d’un S.I : SYSTÈME D’INFORMATION ET SYSTÈME INFORMATIQUE  Pour assurer un traitement automatisé de l’information du S.I à l’aide d’outils informatiques, la méthode Merise propose la démarche d’informatisation suivante :  Schéma directeur : représente la définition, de manière globale, de la politique d’organisation et d’automatisation du S.I. Lors de cette étape, le S.I est découpé en sous- ensembles (ou domaines) homogènes et indépendants, par exemple, les domaines achat, vente… Base d’information Processeur d’information Faits et événements Faits de la base d’information
  • 7. Conception et modélisation d’un système d’information 7 Proposé par A BENDAOUD LES TROIS CYCLES DE MERISE MERISE propose une démarche de réalisation d'un système d’information (SI) qui consiste à traiter un projet informatique en s'appuyant sur trois notions fondamentales:  Vie du projet  Suivi du projet, décision  Formalisation du projet (différents niveaux d’abstraction) Le système d'information est composé des moyens (humains et techniques) nécessaires au stockage et au traitement de l'information d'une organisation. Cycle de vie en cascade Etude préalable ou de faisabilité Etude détaillée Recette test en chaîne Mise en exploitation Réalisation programmation test unitaire Maintenance
  • 8. Conception et modélisation d’un système d’information 8 Proposé par A BENDAOUD Faire une présentation générale du futur système de gestion (matérialisé par les modèles des données et des traitements) et ce qu’il apporte comme améliorations par rapport au système existant. Cette étude doit être réalisée en 4 étapes :  Étape de recueil : analyser l’existant pour détecter les dysfonctionnements du système actuel.  Étape de conception : formalisé les nouvelles orientations permettant de modéliser le futur S.I sur la base, d’une part, des critiques formulées sur le système actuel et d’autre part, des orientations de la direction de l’entreprise.  Étape d’organisation : définir le système futur au niveau organisationnel, c.-à-d. qui fait quoi ?  Étape d’appréciation : établir les coûts et délais de réalisation des solutions préconisées. Au regard de cette ébauche du système futur, proposer divers scénarios. Chaque scénario doit mentionner les éléments Suivants :  Matériels nécessaires.  Logiciels nécessaires.  Grands ensembles d'informations et principaux traitements retenus pour l'automatisation (MCT et éventuellement ébauche du MCD). Les problèmes éventuels ne sont perçus qu’à la mise en exploitation, d’où la préférence donnée au cycle de vie en spirale ÉTUDE DÉTAILLÉE PAR PROJET :  D’une part, détailler les solutions préconisées par l’étude préalable, et d’autre part, rédiger le dossier des spécifications (maquettes, algorithmes associés aux règles de gestion…) permettant de définir le cahier des charges de l’utilisateur qui constitue la base de l’engagement du concepteur vis-à-vis de l’utilisateur.  Réalisation : Obtenir des programmes qui tournent sur un jeu d’essai défini par l’utilisateur.  Mise en œuvre : Transmettre, d’une part, la recette définitive de l’application à l’utilisateur, et d’autre part, former l’utilisateur.  Maintenance : Faire évoluer l’application en fonction des besoins de l’utilisateur et des avancées technologiques. Étude préalable par domaine :
  • 9. Conception et modélisation d’un système d’information 9 Proposé par A BENDAOUD Cycle de vie en spirale Courbe du soleil Analyse conception Merise Prototype V1 Test Mise au point Conception Prototype V2 Test Mise au point Critique (focus point) Conception Version stabilisée Critique (focus point) Prototype V3 Critique Modéles : Données Traitements Flux Interviews Recueil d’information Conceptuel Organisationnel Opérationnel Nouveau modèle Nouveau système d’information Analyse de l’existant Critique Conception réalisation Temps Abstraction
  • 10. Conception et modélisation d’un système d’information 10 Proposé par A BENDAOUD LES SYSTÈMES INFORMATIQUES  Ils comprennent, outre les S.I, les technologies de l’information, les ordinateurs, les applications informatiques, les réseaux et autres systèmes permettant l’accès, l’analyse, la création, l’échange,… de l’information.  En définitive, la méthode Merise est considérée comme une méthode de conception des S.I et non des systèmes informatiques, même si les S.I sont actuellement largement gérés par des applications informatiques, les modèles Merise doivent être utilisées pour faciliter le développement de ces applications en s’appuyant sur les technologies logicielles de B.D relationnelles ou client/serveur.  En guise de conclusion de cette introduction, on dira que l’on traitera au niveau de ce cours les concepts Merise utiles aux descriptions statique et « dynamique » du S.I à automatiser sur 3 niveaux d’abstraction : Le niveau conceptuel Le niveau conceptuel consiste à concevoir le SI en faisant abstraction de toutes les contraintes techniques ou organisationnelles et cela tant au niveau des données que des traitements. Le niveau conceptuel répond à la question Quoi ? (le quoi faire, avec quelles données). Le formalisme Merise employé sera : Le Modèle Conceptuel des Données (MCD). Le Modèle Conceptuel des Traitements (MCT). Niveau organisationnel : Le niveau organisationnel a comme mission d’intégrer dans l’analyse les critères liés à l’organisation étudiée. Le niveau organisationnel fera préciser les notions de temporalité, de chronologie des opérations, d’unité de lieu, définira les postes de travail, l’accès aux bases de données… Les questions posées, au niveau des traitements, sont : Qui ? Où ? Quand ? Le formalisme Merise employé sera : Le Modèle Organisationnel des Données (MOD). Le Modèle Organisationnel des Traitements (MOT). Le niveau logique Le niveau logique est indépendant du matériel informatique, des langages de programmation ou de gestion des données. C’est la réponse à la question Avec quoi ? Le formalisme sera :  Le Modèle Logique des Données (MLD).  Le Modèle Logique des Traitements (MLT). Résumé
  • 11. Conception et modélisation d’un système d’information 11 Proposé par A BENDAOUD Le niveau physique  Le niveau physique permet de définir l’organisation réelle (physique) des données. Il apporte les solutions  techniques, par exemple sur les méthodes de stockage et d’accès à l’information. C’est la réponse au Comment ?  Le formalisme employé sera :  Le Modèle Physique des Données (MPD).  Le Modèle Opérationnel et physique des Traitements (MOpT). Tableau récapitulatif Niveaux Données Traitements Conceptuel Modèle Conceptuel des Données Modèle Conceptuel des Traitements Organisationnel Modèle Organisationnel des Données Modèle Organisationnel des Traitements Logique Modèle Logique des Données Modèle Logique des traitements Physique Modèle Physique des Données Modèle Opérationnel et Physique des Traitements - 2 CYCLES D’ABSTRACTION DE CONCEPTION DES S.I Système d’information actuel Modèle logique Expression des Besoins Modèle conceptuel Modèle physique Système d’information Automatisé
  • 12. Conception et modélisation d’un système d’information 12 Proposé par A BENDAOUD Modèle conceptuel des données Les concepts de base Modèle conceptuel des données INTRODUCTION AU MODÈLE CONCEPTUEL DES DONNÉES Une description détaillée d’un système d’information suppose, implicitement, une description détaillée de l’ensemble d’objets, d’événements ou de concepts concernés par les traitements. Le modèle conceptuel de données (MCD) décrit les objets, les événements, les concepts d’une manière abstraite, sans réfléchir, à ce stade, aux possibilités de traitement par l’ordinateur. Dans la suite, nous étudierons le modèle basé sur le couple entité - association. Le Modèle Conceptuel des Données introduit la notion d’entités, de relations et de propriétés. Nous allons commencer par voir certains aspects « théoriques » avant de plonger dans la pratique. Il décrit de façon formelle les données utilisées par le système d’information. La représentation graphique, simple et accessible, permet à un non informaticien de participer à son élaboration. Les éléments de base constituant un modèle conceptuel des données sont :  les propriétés ;  les entités ;  les relations. LA SÉPARATION DES DONNÉES ET DES TRAITEMENTS 1. LES DONNÉES (OU INFORMATIONS) L’information est l’émission ou la réception de signaux oraux ou écrits, sonores, visuels ou multimédias dont le but est de déclencher les processus alimentant l’échange, base naturelle et indispensable de l’animation de l’organisation. Les informations se recueillent à l’intérieur du domaine à étudier. La liste d’informations est constituée de plusieurs façons :  l’interview ;  l’étude des documents internes ;  l’étude des documents externes. Une des phases du recueil d’information est un entretien avec les différents acteurs de l’organisation. Cet entretien permet de définir le périmètre de l’applicatif futur. Les informations orales sont classées et a. L’interview
  • 13. Conception et modélisation d’un système d’information 13 Proposé par A BENDAOUD regroupées en parties distinctes. Ainsi, les informations concernant l’enregistrement des données de l’organisation seront regroupées. Les documents internes (factures, bons de livraison, ordres de fabrication) recèlent des informations qui sont souvent omises lors des entretiens. Ces oublis sont dus au caractère automatique et récurrent de ces informations. Les personnes qui les manipulent au quotidien oublient souvent de les citer tant elles leur paraissent évidentes. L’étude des documents externes (factures des fournisseurs, bons de livraison fournisseurs...) tout comme l’étude des documents internes permet de découvrir des informations oubliées lors des interviews et de découvrir aussi quelques règles de gestion. Pour ce recueil d’informations, il est nécessaire de respecter certaines règles pour éviter des erreurs futures. Avant d’ajouter une information, il est impératif de s’assurer qu’elle n’est pas déjà présente. Par exemple, un numéro client peut apparaître sur un bon de livraison et sur une facture. Ce n’est pas la peine de le répertorier deux fois. De même, une information peut être synonyme d’une autre. Par exemple sur le bon de livraison il apparaît « Codeclient » et sur la facture « Numéro Client ». Il est impératif de ne garder qu’une seule des deux informations. LES DIFFÉRENTS TYPES D’INFORMATIONS Les informations élémentaires sont des informations dont les valeurs ne peuvent pas être inventées, elles ne sont pas déductibles d’autres informations. La propriété est une information élémentaire (par rapport au domaine étudié), c-à-d qu’elle ne peut pas être déduite à partir d’autres informations. Par exemple, un nom de client ou sa raison sociale ne peuvent pas être inventés. Une quantité commandée ne peut pas non plus être inventée. Une information doit être atomique, c’est à dire non décomposable. Par exemple si l’information Adresse doit contenir « 36, rue de la paix 75000 Paris » celle-ci peut être décomposée en plusieurs informations élémentaires : Adresse ; Code postal ; Ville. Chaque valeur prise par une information est appelée une occurrence. Par exemple, l’information Nom peut avoir les occurrences suivantes : lBRAHIMI ;MOURAD.FAHMI Les informations calculées sont déductibles des informations élémentaires. Par exemple, le total d’une ligne de commande est le résultat de la multiplication du prix de vente hors taxe et de la quantité commandée. Ils sont collectés comme les informations via un processus d’interview et d’étude des documents. b. L’étude des documents internes c. L’étude des documents externes a.Les informations élémentaires et mémorisables b. Les informations calculées c. Les traitements
  • 14. Conception et modélisation d’un système d’information 14 Proposé par A BENDAOUD Ils peuvent être de deux sortes :  Automatiques ;  Manuels. Ils sont déclenchés par l’arrivée d’évènements. La gestion des traitements sert à identifier les fonctionnalités selon une approche qui va du général au particulier et qui définit leur découpage et leur enchaînement. PROPRIÉTÉ (OU ATTRIBUT) La propriété est une information élémentaire (par rapport au domaine étudié), c-à-d qu’elle ne peut pas être déduite à partir d’autres informations. Par exemple, si on considère le domaine de « la gestion des ventes d’une société commerciale », les données :  Référence article » ; « Désignation article »  Prix unitaire HT ; Taux TVA Sont des propriétés « pertinentes » pour ce domaine. En revanche, la donnée « Prix unitaire TTC » n’est pas une propriété, car elle peut être déduite du PU-HT et du T-TVA. Total n’est pas une propriété car il est calculé en fonction de la somme des PU*Qtt Chaque valeur prise par une propriété est appelée occurrence. Par exemple, des occurrences de « désignation article » sont : « ordinateur », « clavier », « souris »… « «brahim », »ahmed », »ali », » fatima» se sont des occurrences de la propriété nom  Une propriété est dite simple (ou atomique) si chacune des valeurs qu’elle regroupe n’est pas décomposable.  Par exemple, la propriété « Adresse », dont un exemple d’occurrences est donné ci-dessous, n’est pas élémentaire car elle peut être décomposée en 3 propriétés : la rue, le code postale et la ville :  125, Boulevard Abdelmoumen 20000 Casablanca. Remarque Dans le MCD, on doit faire apparaître toutes les propriétés identifiées par leurs noms qui doivent être explicites. De plus, il doit y avoir une parfaite correspondance (bijection) entre l’ensemble des noms et l’ensemble des propriétés, cela donne les règles suivantes :  Il faut exclure les synonymes : 2 noms différents pour identifier la même propriété.  Il faut exclure les polysémes : 2 propriétés différentes ayant le même nom.  Principe de non-redondance : chaque propriété doit apparaître une fois et une seule dans le modèle.
  • 15. Conception et modélisation d’un système d’information 15 Proposé par A BENDAOUD Constitution du dictionnaire des données Le dictionnaire des données est un document qui permet de recenser, de classer et de trier toutes les informations (les données) collectées lors des entretiens ou de l’étude des documents. Le dictionnaire peut être plus ou moins élaboré selon le niveau de granularité souhaité. En voici un exemple : Cette étape consiste à référencer toutes les données du domaine. Pour notre service Achat, on peut recenser un certain nombre d’éléments : Nom de la donnée Cette cellule recevra une donnée par exemple : Nom client. Format Ici sera indiqué le format de la donnée, par exemple : alphabétique. Longueur La longueur approximative ou exacte de la donnée sera indiquée, par exemple : 30. Type Une croix sera inscrite dans la colonne pour indiquer si la donnée est élémentaire ou calculée. Règle de calcul Ici sera indiquée de manière claire la formule ou le calcul nécessaire à appliquer pour obtenir la donnée. Règle de gestion Dans cette zone sera indiquée, si nécessaire, la règle de gestion inhérente à la donnée. Document La rubrique document permet de saisir le document dans lequel a été trouvée la donnée. Voici ce que pourrait être le dictionnaire :
  • 16. Conception et modélisation d’un système d’information 16 Proposé par A BENDAOUD  Nom du fournisseur  Date de la commande  Numéro de la commande  Quantité en stock de l’article  Référence de l’article  Prix unitaire de l’article  Désignation de l’article  Quantité commandée  Condition de paiement  Condition de livraison  Téléphone du fournisseur  Adresse du fournisseur  Adresse de livraison  Unité de l’article  Taux de TVA Chaque terme du dictionnaire des données est appelé Propriété. L’étape suivant consiste à regrouper les propriétés dans des entités. LES ENTITÉS L’entité est la représentation d’un élément ayant un rôle dans le système. Une entité possède des propriétés qui la décrivent. Un ensemble d’entités de même type s’appelle une classe d’entités. Chaque entité est unique et est décrite par un ensemble de propriétés encore appelées attributs . Une des propriétés de l'entité est l'identifiant. Cette propriété doit posséder des occurrences uniques et doit être source des dépendances fonctionnelles avec toutes les autres propriétés de l'entité. Bien souvent, on utilise une donnée de type entier qui s'incrémente pour chaque occurrence, ou encore un code unique spécifique du contexte. Le formalisme d'une entité est le suivant :
  • 17. Conception et modélisation d’un système d’information 17 Proposé par A BENDAOUD Ainsi, si on reprend notre dictionnaire de données précédent, on schématise par exemple une entité «Auteur» comme ceci : À partir de cette entité, on peut retrouver la règle de gestion suivante : un auteur est identifié par un numéro unique (id_a) et est caractérisé par un nom, un prénom et une date de naissance. Une entité peut avoir une ou plusieurs occurrences. Pour illustrer ce terme d'«occurrence» qui a déjà été utilisé plusieurs fois, voici un exemple de table d'occurrences de l'entité Auteur : id_a nom_a prenom_a date_naissance_a 1 Hugo Victor 1802-02-26 2 Rimbaud Arthur 1854-10-20 3 de Maupassant Guy 1850-08-05 Cette table est composée de trois occurrences de l'entité Auteur. Remarques :  Les occurrences sont parfois appelés tuples. Par ailleurs, la table d'occurrence peut être comparée à l'instance d'une relation (implantation relationnelle d'une entité ou association) à un moment donné. Nous reviendrons sur cette notion de relation dans la partie III.  Au niveau conceptuel, on devrait plutôt parler d'entités-types , les entités étant en fait des instances d'entités-types. Par soucis de simplicité, on gardera les termes d'entités et associations tout au long du cours. Dans notre cas, trois entités semblent se dégager :  L’entité Fournisseur  L’entité Article  L’entité Commande
  • 18. Conception et modélisation d’un système d’information 18 Proposé par A BENDAOUD Une fois ces entités définies, on leur associe les propriétés du dictionnaire des données. Un premier essai nous donne ceci : Remarque  Une propriété ne peut être dans plusieurs entités. Ici, par exemple, le prix d’un article est une propriété de l’entité Article. Mais dans la mesure où ce prix est négocié en fonction de la commande, il sera nécessaire de disposer de deux propriétés prix : une propriété Prix Article dans l’entité Article et une propriété Prix Commande dans l’entité Commande. Chaque fois qu’une propriété est associée à une entité on le signale dans le dictionnaire de données.  F Nom du fournisseur  C Date de la commande  C Numéro de la commande  Quantité en stock de l’article  A Référence de l’article  A Prix unitaire de l’article  A Désignation de l’article  Quantité commandée  Condition de paiement  Condition de livraison
  • 19. Conception et modélisation d’un système d’information 19 Proposé par A BENDAOUD  F Téléphone du fournisseur  F Adresse du fournisseur  Adresse de livraison  A Unité de l’article  Taux de TVA On se rend compte que certain éléments du dictionnaire de données ne figurent pas dans les entités. Ceci peut être dû à plusieurs causes :  Certains éléments ne sont pas des données. C’est peut être le cas des conditions de paiement. En effet, ces conditions peuvent être le résultat d’un calcul dépendant de la quantité commandée, du délai de livraison, …  Certains éléments ne sont pas dans le domaine étudié. C’est le cas de la quantité en stock de l’article. C’est bien une donnée mais cette donnée concerne la Gestion de stocks et non le service Achat.  Certains éléments sont peut-être des propriétés d’entités que l’on n’a pas encore créées ou ils qualifient une relation entre entités. Par exemple la quantité commandée ne peut être une propriété de l’entité Commande que si une commande ne fait l’objet que d’un seul article, ce qui est un cas particulier. IDENTIFIANT D’UNE ENTITE Une entité est caractérisée par ses propriétés. Parmi ces propriétés il peut y avoir une, plusieurs ou aucune permettant d’identifier une occurrence unique d’une entité. Si une telle propriété existe, elle identifie l’entité. On la nomme identifiant. L’identifiant sert à désigner, sans ambiguïté une occurrence de l’entité. Toute entité doit avoir un identifiant. La méthode Merise propose des représentations graphiques pour la plupart de notions qu’elle utilise. Une entité est représentée par un rectangle dans lequel apparaissent son nom et ses propriétés. Afin de faciliter la lecture des propriétés, le nom de l’identifiant est souligné. Exemple  L’entité client a comme identifiant le numéro client.  L’entité voiture ayant les propriétés : Numéro d’immatriculation, Couleur voiture, Marque a comme identifiant la propriété Numéro d’immatriculation.
  • 20. Conception et modélisation d’un système d’information 20 Proposé par A BENDAOUD RELATIONS OU ASSOCIATION Une association définit un lien sémantique entre une ou plusieurs entités. En effet, la définition de liens entre entités permet de traduire une partie des règles de gestion qui n'ont pas été satisfaites par la simple définition des entités. Le formalisme d'une association est le suivant : Généralement le nom de l'association est un verbe définissant le lien entre les entités qui sont reliées par cette dernière. Par exemple : Ici l'association «être né» traduit les deux règles de gestion suivantes :  Un auteur est né dans un et un seul pays,  Dans un pays, sont nés aucun, un ou plusieurs auteurs. Vous remarquerez, que cette association est caractérisée par ces annotations 1,1 et 0,N qui nous ont permis de définir les règles de gestions précédentes. Ces annotations sont appelées les cardinalités.
  • 21. Conception et modélisation d’un système d’information 21 Proposé par A BENDAOUD Une relation ou association est un lien entre différentes entités. Ces liens se réalisent en se posant la question : quelle entité interagit sur cette ou ces entités.  Par exemple, un fournisseur fournit un article et un article est fourni par un fournisseur. En effet il y a interaction entre les entités Fournisseur et Article que l’on traduit par l’action de Fournir. le prix peut être négocié faire les modifications nécessaires puis ajouter les cardinalités a cette association :  De même, une commande comporte des articles et les articles appartiennent à une commande. La relation entre les entités Commande et Article est l’action de Commander  Une relation peut avoir des propriétés. C’est le cas ici de la propriété Quantité qui est une propriété de la relation Commander. Fournisseur Nom Adresse Téléphone Article Référence Prix Désignation Unité Fournir Fournisseur Nom Adresse Téléphone Article Référence Prix Désignation Unité Fournir Commande Date Numéro Commander Fournisseur Nom Adresse Téléphone Article Référence Prix Unitaire Désignation Unité Fournir Commande Date Numéro Commander Quantité Prix cde. Prix fnr. 0,n 0,n 1,n 1,n
  • 22. Conception et modélisation d’un système d’information 22 Proposé par A BENDAOUD  pour lever l’ambiguïté de la propriété Prix , la propriété Prix Unitaire est associée à l’entité Article, la propriété Prix commande est associée à la relation Commander et la propriété Prix fournisseur est associée à la relation Fournir. C’est une relation qui liée une entité a elle-même : Soit l’exemple suivant : Ici l’entité employé joue deux rôles : rôle d’employé subordonné et rôle d’employé chef, on peut le supposer comme si on a deux entité Employé superposées. La patte de l’association du cardinalité 0,N part d’Employé qui a pour rôle Employé Chef La patte de l’association du cardinalité 1,1 part d’Employé qui a pour rôle Employé subordonné CARDINALITÉS Relation réflexive Employe ID_Emp nom prenom A pour chef 1,1 0,N est chef de
  • 23. Conception et modélisation d’un système d’information 23 Proposé par A BENDAOUD Exemple : Les valeurs 0,n 1,n 1,1 sont des cardinalités.  La cardinalité 1,n de l’entité Commande pour la relation Commander signifie qu’une commande peut avoir au moins un article et au plus N .  La cardinalité 0,N de l’entité Article pour la relation Commander signifie qu’un Article peut ne pas être commandé ou commandé plusieurs fois.  La cardinalité 1,1 de l’entité commande pour la relation Passer signifie qu’une commande est passée par un est un seul client minimum un client et maximum un client  La cardinalité 1,N de l’entité client pour la relation Passer signifie qu’un client passe un ou plusieurs commande Il nous reste l’Adresse de livraison et le Taux de TVA.  L’Adresse de livraison est une propriété de l’entité Commande. Les cardinalités expriment le nombre minimum et maximum de fois qu’une entité est concernée par la relation. Fournisseur Nom Adresse Téléphone Article Référence Prix Unitaire Désignation Unité Fournir Commande Date Numéro Commander Quantité Prix cde. Prix fnr. 0,n 0,n 1,n 1,n Client Code nom prénom Passer 1,N 1,1
  • 24. Conception et modélisation d’un système d’information 24 Proposé par A BENDAOUD  Pour le taux de TVA, il y a deux façons de résoudre le problème :  Soit rattacher le taux à la relation Commander Soit créer une entité Taux de TVA Remarque  On ne peut, dans l’état actuel de nos connaissance, définir qu’elle est la présentation la mieux adaptée au problème. Il se peut de plus que la TVA soit fonction de la nature de l’article et/ou du lieu de livraison (Export, Régime Intra/Extra Communautaire) .  Un MCD ne peut être unique et varie nécessairement en fonction de règles de gestion et de choix du concepteur. Fournisseur Nom Adresse Téléphone Article Référence Prix moyen Désignation Unité Fournir Commande Date Numéro Commander Quantité Prix comm. Taux TVA Prix four. 0,n 0,n 1,n 1,n Fournisseur Nom Adresse Téléphone Article Référence Prix moyen Désignation Unité Fournir Commande Date Numéro Commander Quantité Prix comm. Prix four. 0,n 0,n 1,n 1,n Taux TVA Code TVA Taux TVA 0,n
  • 25. Conception et modélisation d’un système d’information 25 Proposé par A BENDAOUD  Une relation peut ne pas avoir de propriété  Une relation peut être binaire, ternaire, … L’IDENTIFIANT D’UNE ASSOCIATION L'identifiant d'une association ayant des cardinalités 0,N/1,N de part et d'autre, est obtenu par la concaténation des entités qui participent à l'association. Imaginons l'association suivante : Ici un auteur rédige au moins un ou plusieurs livres et pour chaque livre, on connaît le nombre de chapitres rédigés par l'auteur (on connaît aussi le nombre total de chapitres pour chaque livre). L'association «rédiger» peut donc être identifiée par la concaténation des propriétés id_a et id_l. Ainsi, le couple id_a, id_l doit être unique pour chaque occurrence de l'association. On peut également définir la dépendance fonctionnelle suivante : id_a, id_l → nb_chapitres On dit que nb_chapitres (nombre de chapitres rédigés par un auteur, pour un livre) est une donnée portée par l'association «rédiger». Cette association est donc une association porteuse de données. Pour une association ayant au moins une cardinalité de type 0,1 ou 1,1 considérons dans un premier temps que cette dernière ne peut être porteuse de données et qu'elle est identifiée par l'identifiant de l'entité porteuse de la cardinalité 0,1 ou 1,1. Nous reviendrons plus en détail sur la notion d'identification d'une association lors du passage au modèle logique.
  • 26. Conception et modélisation d’un système d’information 26 Proposé par A BENDAOUD RELATION TERNAIRE Une relation binaire est une relation qui lie deux entités Une relation térnaire est une relation qui lie trois entités On peut avoir des relations d’ordre N se sont des relations qui lient N entités Exercice de réflexion : Dans un cabinet médical les patients sont consultés par les médecins,un patient choisit le medecin avec qui il va faire la consultation Le premier modèle conceptuel relatif est : Les informations concernant la relation « consulter » peuvent être représenté comme si on a une entité qui a pour identifiant la concaténation des identifiants qui participent à la relation « consulter » ; Les entités qui participent à la relation sont médecin et patient d’où l’identifiant de la relation est (codeM,codeP) Toutefois les valeurs d’un identifiant sont unique c à d on ne peut pas avoir deux valeurs identiques (a,b)<>(a’,b’)a<>a’ ou b<>b’ (a,b)=(a’,b’)a=a’ et b=b’ Medecin codeM nomM telephoneM Patient codeP nomP telephoneP consulter dateConsultation 0,N 1,N Fournir Commander Quantité Prix comm. Prix four. Relation binaire Relation ternaire
  • 27. Conception et modélisation d’un système d’information 27 Proposé par A BENDAOUD Cette premiére modélisation ne permet pas à un patient de faire plusieurs consultations par un même médecin qui n’est pas logique. M1 fait la consultation de p1 le 03/04/17 mais M1 ne peut pas fait la consultation de p1 le 10/04/17 puisque l’identifiant de l’association est (codeM,codeP). Le triplet (M1,P1,03/04/17) est diffèrent du triplet(M1,P1,10/04/17),donc si on ajoute la date de Consultation a l’identifiant de l’association consulter, le modèle peut supporter le cas « un patient peut être consulté par plusieurs médecins a des dates différentes D’où on aura le MCD suivant : L’identifiant de l’association Visiter devient (codeM,codeP,dateVisite) TRANSFORMATION D’UNE RELATION EN UNE ENTITÉ En réalité dans une cabiné médicale quand un patient effectue une consultation, une fiche de consultation va être remplit par les informations du patient et le numéro du médecin qui a fait la consultation, puis le rapport des pathologies du patient. D’où la relation consultation peut être remplacer par une entité « consultation » qui possède un identifiant codec,et comme ça on se retrouve avec une modélisation qui représente fidèlement la réalité Medecin codeM nomM telephoneM Patient codeP nomP telephoneP consulter dateConsulta tion 0,N 1,N date datevisite 0,N
  • 28. Conception et modélisation d’un système d’information 28 Proposé par A BENDAOUD Medecin codeM nomM telephoneM Patient codeP nomP telephoneP passer 0,N 1,N effectuer consultation codeC dateC 1,1 1,1
  • 29. Conception et modélisation d’un système d’information 29 Proposé par A BENDAOUD Dépendance fonctionnelle Notion de Dépendance Fonctionnelle Formalisme : A B : 1 source, 1 but ( A, B, …) X : plusieurs sources, 1 but A ( X, Y, …) : 1 source , plusieurs buts Exemples N° Client Nom Client Nom Client N° Client ( pas de DF) Prénom Client N° Client ( pas de DF ) ( Réf-prod , N° Commande ) Qté prod. commandée Réf-prod ( Libellé prod. , Prix unit. Prod. ) DÉPENDANCE FONCTIONNELLE ÉLÉMENTAIRE Définition : 2 propriétés A et B sont en DF si la connaissance d’une valeur de A détermine une et une seule valeur de B . On dit que A détermine fonctionnellement B . Une dépendance fonctionnelle A → B est élémentaire s’il n’existe pas une donnée C, sous ensemble de A, décrivant une dépendance fonctionnelle de type C → B
  • 30. Conception et modélisation d’un système d’information 30 Proposé par A BENDAOUD Par exemple : 1- RéférenceProduit → Désignation 2- NuméroCommande, RéférenceProduit → Quantité 3- NuméroCommande, RéférenceProduit → Désignation La première dépendance fonctionnelle est correcte car ayant une rubriques elle est élémentaire. La deuxième dépendance fonctionnelle est correcte également car la connaissance d’un numéro de commande et d’une référence produit nous permet de connaître la quantité commandé du produit. Elle est aussi élémentaire car c’est la connaissance du couple (NuméroCommande, RéférenceProduit) et pas seulement d’un des éléments qui permet la connaissance de la quantité. La troisième dépendance fonctionnelle n’est pas élémentaire car il existe à l’intérieur d’elle RéférenceProduit → Désignation DÉPENDANCE FONCTIONNELLE ÉLÉMENTAIRE DIRECTE Exemple : NumClasse → NumElève NumEleve → NomElève NumClasse → NomElève La troisième dépendance fonctionnelle n’est pas directe car nous pourrions écrire : NumClasse → NumElève → NomElève GRAPHE DE DÉPENDANCES FONCTIONNELLES GDF = Représentation graphique de l’ensemble des DFs unissant les propriétés dans un domaine d’activité du système d’information. Ces propriétés sont obtenues à partir du dictionnaire de données du domaine. Exemple : GDF du domaine « Gestion commerciale » dans une entreprise On dit que la dépendance fonctionnelle A → B est directe s’il n’existe aucun attribut C tel que l’on puisse avoir A → C et C → B. En d’autres termes, cela signifie que la dépendance fonctionnelle entre A et B ne peut pas être obtenue par transitivité.
  • 31. Conception et modélisation d’un système d’information 31 Proposé par A BENDAOUD PERSONNALISATION D’ASSOCIATIONS BUT : Transformer une association en entité lorsqu’il y a une perte sémantique dans le MCD par rapport aux règles de gestion du S.I 0,N Client N client Nom Client Adresse Client Voiture Matricule marque chevaux ASSUREURE N Assureur Nom Assureur Adresse Assureur Assurer dateSignature date echeance montant prime 1,N 0,N
  • 32. Conception et modélisation d’un système d’information 32 Proposé par A BENDAOUD Selon le modèle, le client ne peut signer qu’un seul contrat d’assurance pour un véhicule donné avec le même assureur d’après la structure de l’identifiant de l’association. Solution : Personnaliser l’association « Assurer » en entité D’où maintenant Un client peut signer plusieurs contrats d’assurance relatifs au même véhicule chez le même assureur. 1 ,1 ASSUREURE N Assureur Nom Assureur Adresse Assureur Client N client Nom Client Adresse Client Voiture Matricule marque chevauxCONTRAT N Contrat Date signature Date écheance Montant Prime CIF CIF CIF 1,N 1,N 1,N 1,11,1 1,1
  • 33. Conception et modélisation d’un système d’information 33 Proposé par A BENDAOUD DÉPENDANCES FONCTIONNELLES PARTICULIÈRES ET REPRÉSENTATIONS MERISE 2
  • 34. Conception et modélisation d’un système d’information 34 Proposé par A BENDAOUD Les formes normales INTRODUCTION Nous allons aborder dans ce document les principes de normalisation des données. Nous parlerons de modèles de données conforment à la 1ère , 2ème ou 3ème forme normale. Dans une base de données relationnelle, une forme normale désigne un type de relation particulier entre les entités. Comme son nom l’indique, normale décrit la norme. La normalisation s’applique à toutes les entités et aux relations porteuses de propriétés. On dira d’un modèle qu’il est en première, deuxième ou troisième forme normale. Il s’agit là des règles de normalisation les plus importantes, d’autres règles pouvant être appliquées mais de manière non systématique. La forme normale vient après la simple validité d'un modèle relationnel, c'est-à-dire que les valeurs des différents attributs soient bien en dépendance fonctionnelle avec la clé primaire (complètement déterminés par la clé primaire). En pratique, la première et la deuxième forme normale sont nécessaires pour avoir un modèle relationnel juste. Les formes normales supplémentaires ont leurs avantages et leurs inconvénients. Definition La normalisation des modèles de données permettra donc de s’assurer de la robustesse de la conception de la base pour améliorer la modélisation (et donc obtenir une meilleure représentation) et optimiser la mémorisation des données en évitant la redondance et les problèmes sous-jacents de mise à jour ou de cohérence.
  • 35. Conception et modélisation d’un système d’information 35 Proposé par A BENDAOUD Les avantages sont :  de limiter les redondances de données  de limiter les incohérences de données qui pourraient les rendre inutilisables  d'éviter les processus de mise à jour récurrents Les inconvénients sont :  des temps d'accès qui peuvent être plus longs si les requêtes sont trop complexes  un manque de flexibilité au niveau de l'utilisation de l'espace de stockage La troisième forme normale reste généralement une des meilleures solutions d'un point de vue architecture de base de données, mais pour des bases de données plus importantes, cela n'est pas toujours le cas. Il s'agit de choisir l'équilibre entre deux options :  la génération dynamique des données via les jointures entre tables  l'utilisation statiques de données correctement mises à jour  La normalisation des modèles de données a été popularisée principalement par la méthode Merise. La principale limite de la normalisation est que les données doivent se trouver dans une même base de données (dans un seul schéma). Avantages et inconvénients
  • 36. Conception et modélisation d’un système d’information 36 Proposé par A BENDAOUD Exemple  client (code Cl, nom&prenom, age) n’est pas en 1FN car nom&prenom n’est pas atomique on eclate la propriété nom&prenom client (code Cl, nom,prenom, age) client n’est en 1FN car âge n’est pas constant dans le temps client (code Cl, nom,prenom,dateNaissance)  Article(ref,designation,codeCategorie) n’est pas en 1FN car codeCategorie est répétitive d’où on crée une entité categorie  Notée 2FN - deuxième forme normale La première forme normale : Notée 1FN - première forme normale : Respecte la première forme normale, la relation dont tous les attributs : 1- contiennent une valeur atomique. Ainsi, le nom et le prénom d’une personne doivent être dans des propriétés distinctes. 2-contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste dans un seul attribut). On pourrait citer pour exemple une catégorie d’articles qui doit être définie dans une entité spécifique et non répétée dans l’entité article. 3-sont constants dans le temps (utiliser par exemple la date de naissance plutôt que l'âge). La deuxième forme normale Respecte la seconde forme normale, la relation respectant la première forme normale et dont : Tous les attributs non-clés ne dépendent pas d'une partie de la clé primaire mais bien de la totalité de la clé primaire. Article Ref designation Categorie codeCategorie nomCategorie Appartient 1,1 0,N
  • 37. Conception et modélisation d’un système d’information 37 Proposé par A BENDAOUD  Le non-respect de la 2FN entraine une redondance des données qui encombrent alors inutilement la mémoire et l'espace disque. Autrement dit et exemple!!  Une relation est dite en deuxième forme normale si elle est en première forme normale, et si tout attribut n'appartenant pas à la clé primaire ne dépend pas d'une partie de cette clé. EXEMPLE
  • 38. Conception et modélisation d’un système d’information 38 Proposé par A BENDAOUD LA TROISIÈME FORME NORMALE  Notée 3FN - troisième forme normale Autrement dit et exemple!!  Une relation est dite en troisième forme normale si elle est en deuxième forme normale, et si toutes les dépendances fonctionnelles issues de la clé primaire sont directes. Exemple1  R-MATERIEL (code matériel, libellé matériel, code marque, libellé marque)  La dépendance entre "code matériel" et "libellé marque" n'est pas directe, "libellé marque" est en dépendance fonctionnelle directe avec le "code marque". code matériel code marque libellé marque  La relation doit être éclatée en deux, pour être exprimée en troisième forme normale : Respecte la troisième forme normale, la relation respectant la seconde forme normale et doit avoir tous les attributs n'appartenant pas à la clé ne dépendent pas d'un attribut non-clé. En d'autre terme, la dépendance fonctionnelle est directe.
  • 39. Conception et modélisation d’un système d’information 39 Proposé par A BENDAOUD Le Modèle logique de données INTRODUCTION Le MCD est une représentation du réel tel qu’il est perçu par l’utilisateur. Ce modèle, en tant que formalisme (définir les entités, les associations et les propriétés et leur enchaînement chronologique et fonctionnel) est commandé par l’utilisateur et donc, n’est pas remis en cause par un changement de matériel ou de logiciel ou par des changements issus des contraintes organisationnelles.  De ce point de vue, le MCD constitue, dans l’ensemble des modèles proposés par la méthode Merise, le modèle le plus stable. PROBLÉMATIQUE :  Toutefois le MCD reste un modèle abstrait. Les concepts (leurs définitions et leurs comportements) ne sont pas représentés d’une manière qui pourrait conduire à un traitement informatique facile et rapide.  D’où la nécessité d’une étape intermédiaire - modèle logique des données (MLD) - proposant une représentation de données en vue de leur traitement par ordinateur. TRANSFORMATION D’UN INDIVIDU OU ENTITÉ TYPE  Toute entité devient une table. Ses propriétés deviennent des attributs de la table (colonne).  L’identifiant devient la clé primaire unique de la table. R-MATERIEL codemateriel libellé materiel R-marque codemarque libellé marque Appartient 1,1 0,N
  • 40. Conception et modélisation d’un système d’information 40 Proposé par A BENDAOUD TRANSFORMATION D’UNE RELATION BINAIRE (0,N)-(1,1) OU (1,N)-(1,1)  On duplique la clé issue de l’identifiant de l’individu porteur de la cardinalité (0,n) ou (1,n) dans la table issue de l’individu à cardinalité (1,1).Celle-ci devient alors une clé étrangère.  L’entité B est une entité source (ou entité père). L’entité A est une entité cible (ou entité fils). La transformation se fait selon le principe : le père donne son nom à son fils. Le fils attire le père  Donc, l’entité père (l’entité B) donne son identifiant à l’entité fils (l’entité A). Exemple : Un Employé utilise un est un seul Ordinateur un ordinateur est utilisé par plusieurs Employés MAISON IdMaison Date Construction Surface MAISON IdMaison DateConstruction Surface entité table 1 ,1
  • 41. Conception et modélisation d’un système d’information 41 Proposé par A BENDAOUD SOLUTION MCD MLD Personne Code Nom prenom Maison IdMaison DateConstruction Surface Possede DateP 0,n 1,1 Personne Code Nom prenom Maison IdMaison DateConstruction Surface #Code DateP ORDINATEUR Num type Modele Employe Code nom prenom 1,N 1,1
  • 42. Conception et modélisation d’un système d’information 42 Proposé par A BENDAOUD TRANSFORMATION D’UNE RELATION BINAIRE (0,N)-(0,1) OU (1,N)-(0,1) Deux solutions :  Création d’une table avec comme clé primaire l’identifiant de l’individu porteur de la cardinalité (0,1) et comme clé étrangère l’identifiant de l’individu porteur de la cardinalité (*, n).  Duplication de l’identifiant de l’individu porteur de la cardinalité (*, n) dans la table issue de l’individu porteur de la cardinalité (0,1) qui devient alors une clé étrangère. Il faut pour cette deuxième solution que le SGBD cible accepte des valeurs nulles pour la clé étrangère. Le fils attire le père Exemple : Remarque l’association Possède contient la propriété DateP Solution 1 0,n 0,1 Personne Code Nom prenom Maison IdMaison DateConstruction Surface Possede DateP
  • 43. Conception et modélisation d’un système d’information 43 Proposé par A BENDAOUD Solution 2 : TRANSFORMATION D’UNE RELATION BINAIRE (0,1)-(1,1) La clé issue de l’identifiant de l’entité porteuse de la cardinalité (0,1) est dupliquée dans la table issue de l’entité porteuse de la cardinalité (1,1) et devient une clé étrangère. L’association Parrain est une association porteuse car elle contient la propriétés DateP Personne Code Nom prenom Maison IdMaison DateConstruction Surface Possede IdMaison Code DateP Personne Code Nom prenom Maison IdMaison DateConstruction Surface #Code DateP Contact IdContact Nom prenom Stagiaire IdStagiaire DateNaissance #IdContact DateP 0 ,1 1,1Parrain dateP Contact IdContact Nom prenom Stagiaire IdStagiaire DateNaissance
  • 44. Conception et modélisation d’un système d’information 44 Proposé par A BENDAOUD TRANSFORMATION D’UNE RELATION BINAIRE (0,1)-(0,1)  C’est une particularisation des cas précédemment traités. 2 types de solutions sont possibles Les solutions Type de solution : Créer une table avec comme attributs les identifiants des individus en relation et comme clé primaire l’un des identifiants d’une des deux tables. Les deux attributs sont des clés étrangères. 1,1 Correspond 0,1 ENTREPRISE IDEntreprise Raison Sociale … TIERS IdTiers … 0,1
  • 45. Conception et modélisation d’un système d’information 45 Proposé par A BENDAOUD Exemple de schémas relationnels :  Table ENTREPRISE(IDEntreprise, RaisonSociale,…)  Table TIERS (IdTiers,…)  Table CORRESPOND (Idtiers, IDEntreprise) ou table CORRESPOND(IdTiers, IDEntreprise) 2 type de solution : Duplication de la clé d’une des deux tables issues des entités types dans l’autre table.  Table ENTREPRISE (IDEntreprise,RaisonSociale,…,IDtiers)  Table TIERS (IdTiers,…) OU  Table ENTREPRISE (IDEntreprise,RaisonSociale,…)  Table TIERS (IdTiers,…,IDEntreprise) TRANSFORMATION D’UNE RELATION BINAIRE (*,N)-(*,N)  La table LOUER aura comme schéma relationnel LOUER (Code, IDMaison, DateEntree) l’association Louer est une association porteuse car elle contient la propriétés DateEntree solution : La solution consiste à créer une table dont la clé sera une clé composée des identifiants des deux entités en relation. Les propriétés éventuelles de la relation seront des attributs de la table. Personne Code Nom Prenom Maison IDmaison Numero rue codePostal Louer dateEntree 0,n 0,n
  • 46. Conception et modélisation d’un système d’information 46 Proposé par A BENDAOUD TRANSFORMATION D’UNE RELATION TERNAIRE ET SUPÉRIEURE QUELLES QUE SOIT LES CARDINALITÉS  La relation donne lieu à la création d’une table qui aura comme clé primaire une clé composée des identifiants des individus sur lesquels portent la relation. MAISON IdMaison DateConstruction Surface ENTREPRISE IdEntreprise Raison Sociale … TYPE TRAVAUX IdTypeTravail Désignation Travail … Réaliser Date Réalisation *,n *,n *,n
  • 47. Conception et modélisation d’un système d’information 47 Proposé par A BENDAOUD  La table REALISER aura comme schéma relationnel  REALISER (IdEntreprise, IDMaison, IdTypeTravail, DateRealisation) Application  Trouvez le modèle logique de données Solution :
  • 48. Conception et modélisation d’un système d’information 48 Proposé par A BENDAOUD Application 2 Solution :
  • 49. Conception et modélisation d’un système d’information 49 Proposé par A BENDAOUD Application 3 Solution :
  • 50. Conception et modélisation d’un système d’information 50 Proposé par A BENDAOUD Application 4 APPLICATION DES RÈGLES DE PASSAGE SUR UNE RELATION RÉFLEXIVE Soit l’exemple suivant Le Modèle logique équivalent est : Avion numV marque nbplaces vol numVo DateVo ville numV nomV Utilise Escale Départ Arrivé 1,N 1,1 1,1 1,1 0,N 0,N 0,N 0,N Employe ID_Emp nom prenom Est chef de A pour chef 1,1 0,N Employe ID_Emp nom prenom #ID_EmpChef
  • 51. Conception et modélisation d’un système d’information 51 Proposé par A BENDAOUD Exemple 2 Le Modèle logique équivalent est : APPLICATION DES RÈGLES DE PASSAGE SUR UNE ENTITÉ FAIBLE Exemple1 : On a un hôtel qui est constitué de plusieurs étages, les chambres sont numérotées de 1 à 10 sur chaque étage. Etage4 1 2 3 4 5 6 7 8 9 10 Etage 3 1 2 3 4 5 6 7 8 9 10 Etage2 1 2 3 4 5 6 7 8 9 10 Etage1 1 2 3 4 5 6 7 8 9 10 Ici l’entité chambre est une entité faible car NumCh tout seul ne peut pas definir une chambre, une chambre est bien défini si on spécifie l’etage, d’où NumEt,NumCh une chambre,une entité faible est représenté par (1,1) D’où le modèle logique équivalent est : Article Ref Designation Prix Composition Qtite 0,N 0,N Article Ref Designation Prix Composition Ref Ref Composant Qtite Hotel NumHo Adresse Etage NumEt Chambre NumChAppartient Appartient 1,N 1,1 1,N (1,1)
  • 52. Conception et modélisation d’un système d’information 52 Proposé par A BENDAOUD Remarque : NumEt est dupliqué sur la table Chambre autant que clé étrangère et clé primaire car chambre est une entité faible. Exemple 2 D’où le modèle logique équivalent est : Hotel NumHo Adresse Etage NumEt #NumHo Chambre NumCh #NumEt jour NumJ NomJ semaine NumS Annee Annee Appartient (1,1) 1,N Appartient (1,1) 1,N jour NumJ NumS Annee NomJ semaine NumS Annee Annee Annee