Upload
buibao
View
224
Download
0
Embed Size (px)
Citation preview
Ingénierie des Systèmes d’Information Problématique et méthodologie : illustration avec la méthode MERISE.
Chap 4: Modélisation des Données. MCD Erwan TRANVOUEZ [email protected]
2/55
Plan de la session
Modele Conceptuel de Données Objectifs Concepts
Extension du modèle Entité Association Héritage …
Cas X
1. Modèle Conceptuel des Données
Objectifs Concepts
4/55
Objectifs du Modèle Conceptuel de Données Représente la partie statique du SI: les
informations. Il s’agit d’identifier et de caractériser les objets du discours et leurs interrelations…
Un MCD : énumère l’ensemble des informations du domaine
d’étude les structure et les organise dans un langage clair sans tenir compte des objectifs d’informatisation ni
des contraintes matérielles (relève d’un aspect organisationnel et pas conceptuel, donc remis à plus tard).
5/55
Construction du MCD
S’appuie sur l’existant : Documents manipulés (facture, Bon de Commande,
procédures) Entretiens acteurs du domaines (description de leur
activité en contexte, problèmes rencontrés …) S.I. déjà informatisé (BD, Interfaces, etc…)
Ou sur l’identification des informations nécessaires liste d’informations
suivie de leur caractérisation propriétés descriptives
6/55
Construction du MCD
Cette énumération nécessite des cycles de refactorisation régulier Identification des synonymes Ex: société, Entreprise, Compagnie => unification/réification : Entreprise
Explicitation des ambiguïtés Livre : œuvre, édition, exemplaire papier => développement : définition d’une entité par
concept… ceci évitera des relations ambigües (ex. « emprunter un livre »)
Simplification des relations 1 ternaire -> 2 binaires (cf. ci après)
7/55
Formalisme employé
Comparable au modèle Entité-Relation (E-R) Concepts :
Entité-type Relation-type Propriété-type Cardinalité
1,1
StageidStageintitulédescriptionduree
0,n
EntrepriseidEntreprisenomraison socialeadresseCAAnnuel
proposeproposer
8/55
Exemple d’abstraction : Entités
Informations récoltées : L’entreprise X a embauché M. Maque (promo 2050) L’entreprise Y a embauché M. Paul (promo 2050) L’entreprise X a embauché Mlle. Quarteney (promo 2051)
Il y a 5 individus pouvant être ici regroupés en 2
types d’entité (ou entité-type) Entreprise Eleve
Apparté : individu peut avoir pour synonyme
occurrence, exemplaire, instance, objet …
9/55
Exemple d’abstraction : Propriétés
Informations récoltées : L’entreprise X a embauché M. Maque (promo 2050) L’entreprise Y a embauché M. Paul (promo 2050) L’entreprise X a embauché Mlle. Quarteney (promo 2051)
Dans le texte certains mots caractérisent ou font référence à d’autres : X,Y sont les noms des entreprises Maque, Paul, Quartenay sont les noms des élèves promo 2050 et promo 2051 sont les promos auxquelles ont
appartenu les élèves Peuvent également être abstrait et devenir obligatoire pour
tout nouvel individu d’une entité-type. Entreprise <- nom Eleve <- nom
<- promo
10/55
Exemple d’abstraction : Relation
Informations récoltées : L’entreprise X a embauché M. Maque (promo 2050) L’entreprise Y a embauché M. Paul (promo 2050) L’entreprise X a embauché Mlle. Quarteney (promo 2051)
Ces entités une fois identifiées sont liées entre elles par des relations explicites Une entreprise peut embaucher des élèves Un(e) élève peut être embauché(e) par une entreprise C’est la même relation mais lue dans des sens différents
Embaucher(Entreprise, Eleve)
11/55
Exemple d’abstraction : Cardinalité
Le nombre d’individu pouvant participer à la relation peut être précisé : Un élève est embauché par 1 entreprise au maximum (0 s’il
n’a pas d’emploi). Une entreprise (ex. X) peut embaucher plusieurs élèves
(voire 0). Une entreprise peut embaucher 0 à n élèves. Un élève peut être embauché par 0 ou 1 entreprise.
0,nEntreprise
Nom 0,1 EleveNomPromo
embaucher
12/55
Exemple d’abstraction : Reformulation
Informations pouvant être rajoutées : Le salaire d’embauche : c’est une information supplémentaire
qui caractérise la relation entre Entreprise et futur employé. La notion de promotion est en fait plus générale ou extérieure à
un(e) élève Un(e) élève fait partie d’une promotion mais l’inverse n’est pas
vraie Une promotion a (normalement) plusieurs éleves
Création d’une nouvelle entité : Promotion avec année comme propriété.
Rappel : au niveau conceptuel on cherche à tout expliciter pour ne pas
avoir de problème par la suite à cause d’une information ambiguë ou mal définie …
... mais cela ne préjuge pas totalement de la solution d’informatisation (ex: entité remplacée par propriété)
13/55
Exemple d’abstraction : Résultat
Un MCD brut (manque des informations) mais qui clarifie le dialogue…
0,nEntreprise
Nom 0,1
1,1
EleveNom
embaucherSalaire
1,n
PromotionAnnée
appartenir
14/55
Propriété
Propriété : morceau d’information n’existant pas seul, élémentaire Nom : toto, titi, tutu Solde : 10, 1000, -3
Une propriété peut être décrite comme étant composée d’autres propriétés.
Ex: adresse composée D’une dénomination de lieu : rue, avenue, boulevard D’un numéro D’un nom de bâtiment D’une ville D’un code postal Etc…
15/55
Concepts Entité type
Entité : modélise les objets du discours Définit une classe d’objet : un stage Généralise un ensemble d’occurrences : une
entreprise -> (Etp X, Etp Y, Etp Z) Règles de modélisation Règle de pertinence : l’entité modélise un objet
nécessaire concret ou abstrait du monde réel. Ex: Personne <-> EleveIngénieur/ContactEtp
Règle d’Identification : chaque occurrence doit être identifiée. Chaque entité a donc une propriété dont la valeur est unique pour une entité dans le temps.
16/55
Concepts Entité type
Règles de modélisation Règle de distinguabilité : 2 occurrences ne
peuvent être confondues. Ex: différence entre un livre et un exemplaire.
Règle de vérification ou de non-répétitivité: doit être applicable à toute les occurrences d’une entité à un instant donné : chaque propriété ne peut avoir qu’1 seule valeur. Sinon, cette information doit être externalisée.
Entreprise idEtp Nom Raison Sociale Adresses -rue -batiment ….
Entreprise idEtp Nom Raison Sociale
Adresse idAdresse Rue batiment
posseder
1,n 0,n
17/55
Concepts Entité type
Règles de modélisation (fin) Règle de d’homogénéité : Toutes les propriétés
sont utiles (et donc utilisées). Sinon : soit il y a une erreur de modélisation => héritage
soit il faut accepter que ces propriétés peuvent être nulles ex. Stage sans sujet
18/55
Concepts Relation type
Caractérise des liens entre des occurrences de plusieurs entités
Le schema ci-dessous se lit : 1 stage est proposé par 1 entreprise et 1 seule
1 entreprise propose 0 ou n stage (ie pas de limite max)
1,1
StageidStageintitulédescriptionduree
0,n
EntrepriseidEntreprisenomraison socialeadresseCAAnnuel
propose
Cardinalité Min..max
Nom de la relation Et eventuellement propriétés
Dépendance fonctionnelle
proposer
19/55
Concepts Relation type
La relation peut avoir des propriétés Exemple d’occurrences de cette relation
Université de Grak recoit 1500€ de l’entreprise X Université de Grak recoit 1000€ de l’entreprise Y L’école de Vanne recoit 1800€ de l’entreprise X
Plusieurs relations peuvent reliées en même temps 2 entités
0,n
0,n
EntrepriseidEntreprisenomraison socialeadresseCAAnnuel
0,n
0,n
EtablissementidEtablissementnomvillespecialité
verser TxAppsomme
etre en relation commerciale
20/55
Concepts Relation type
Cas des relations dites réflexives :
0,nfilleul
0,nparrainEleveIngenieur
idEleveAnnéePromotionnomprenomage
recommanderNote
Rôle
21/55
Concepts Cardinalité
Précise ou contraint le nombre de participations à la relation : Min : nombre minimum d’occurrence Max : maximum Au niveau conceptuel, la cardinalité mini peut être laissée
indéterminée (?).
Participation Optionnelle Obligatoire
Unique 0,1 1,1
Multiple 0,n 1,n
22/55
Cardinalité : cas des relations ternaires Ex d’occurrence :
M. Dupond a visite M. Dupont dans l’Entreprise Dupons Cardinalités : elles traduisent les participations à la relation.
Enseignant (1,n) : tout enseignant doit visiter au moins une fois. EleveIngenieur(0,n): 1 élève peut ne pas avoir de visite ou
recevoir plusieurs visites…
1,n
EnseignantidEnseignantnomprenomadressespecialité
0,n
EntrepriseidEntreprisenomraison socialeadresseCAAnnuel
0,n
EleveIngenieuridEleveAnnéePromotionnomprenomage
visiterAttention : le langage ne dispose encore d’un vocabulaire limité. Ex. Il n’est pas possible de dire qu’un enseignant ne visite qu’une seule fois une entreprise (ou inversement) sans rajouter d’autres information (ex. CIF)
23/55
Cardinalité : cas des relations ternaires Que signifie concrètement « participer à la relation »
Un triplet de 3 occurrences de chaque entité peut être constitué pour établir la relation « visiter »
La cardinalité 1..n de la patte de la relation Visiter qui relie à Enseignant impose que toute occurrence d’Enseignant participe au - 1 fois à cette relation.
A l’opposé, il est possible qu’une occurrence d’Entreprise ne se trouve pas dans le tableau ci-dessous (ex. entreprise enregistrée comme fournisseur de la formation qui bien qu’elle reçoivent des demandes de stages n’y réponds pas).
1,n
EnseignantidEnseignantnomprenomadressespecialité
0,n
EntrepriseidEntreprisenomraison socialeadresseCAAnnuel
0,n
EleveIngenieuridEleveAnnéePromotionnomprenomage
visiter
Enseignant EleveIng Entreprise Pr Tourne M. Baille PME SARL MdC Sol M. Cikle Gd Comte SA Dr Schnock M. Keen PaÏ SSII Pr Tourne M. Keen PaÏ SSII MdC Ornet M. Mercry HAL SA
Occurrences de la Relation visiter
2. Extension au modèle E-R
Héritage …
25/55
Notion d’Héritage
Elle s’impose dans 2 cas : Généralisation : ayant identifié 2 entités fortement similaire
(avec relations dupliquées par ex.), on crée une classe qui factorise les propriétés communes.
Spécialisation: 1 entité peut avoir des propriétés vides ou des relations qui ne concernent pas toutes les occurrences. On crée alors des sous classes auxquels on rajoute les propriétés supplémentaires.
La classe qui hérite est supposé disposer des mêmes propriétés et relations de la classe mère.
Il peut y avoir des restrictions sur les héritages possibles
26/55
Notion d’Héritage : Illustration
1 entité pour beaucoup d’informations: Un employé (resp. un étudiant) aura les
propriétés (1) nulles (resp. (2)) Si une relation Verser_bourse était créée
entre Personne et Crous elle impliquerait toutes les occurrences de Personne donc les employés aussi.
=> requiert de vérifier pour chaque Personne qu’il est bien étudiant => vérification faîte au niveau traitement.
Solution: spécialiser Personne avec 2 sous classes
Etudiant et Employé permettant de distinguer des cas spécifiques (relation verser_bourse et verser_salaire)
PersonneidPersonneNomPrenomAgeDate de naissanceAnciennetéTypeConcoursDiplômeSalaire
2
1
1
27/55
Notion d’Héritage : Illustration
Information répétées sur 2 entités : Redondance d’information inutile (propriété, relation
par ex. etre_client_banque) Un étudiant est aussi un employé => duplication des
informations avec nécessité de définir des traitements assurant l’intégrité des données (modification dans une entité répercutée sur l’autre).
Solution : factorisation/généralisation/réification des informations communes dans une entité « mère »
EmployéidEmployéNomPrenomAgeDate de naissanceAnciennetéSalaire
EtudiantidEtudiantNomPrenomAgeDate de naissanceTypeConcoursDiplôme
Propriétés identiques
28/55
Notion d’Héritage : exemple
1,1 1,1
PersonnelidPersonnelnomprenomadresse
0,n
AdministratifCategorie
1,n EnseignantsectionCNU
XT
0,n
1,n
EtablissementidEtablissementnomvillespecialité
affecter
enseignermatiere
gerer
29/55
Notion d’Héritage : Contraintes
Pas de contraintes : tout est possible, une occurrence peut ne pas utiliser l’héritage
Exclusivité : si utilisé il faut choisir !
LyceeidEtablissementnomvillespecialité
EtabPublic Professionel
XT T
EtabPrivé General
X
X
1 Lycée peut être un Etablissement public ou privé, ou aucun des 2. (pas d’établissement privé ET public)
1 Lycée peut être un Etablissement professionnel, général, les 2 ou aucun des 2.
30/55
Notion d’Héritage : Contraintes
Totalité : il est obligé d’utiliser l’héritage mais les choix sont ouverts
Partition : Il faut choisir un sous-type
T
LyceeidEtablissementnomvillespecialité
EtabPublic Professionel
XT T
EtabPrivé General
XT
1 Lycée doit être un Etablissement professionnel, général ou les 2.
1 Lycée doit être un Etablissement public ou privé (mais ne peut être les deux).
31/55
Contraintes intra relations : notion de dépendance fonctionnelle
Notion de dépendance fonctionnelle : A → B : a → b=r(a) A 1 élément de A correspond au plus 1 élément de B
De même: AxB → C : (a,b) → c=r(a,b) A 1 couple (a,b) de A et B correspond au plus 1 élément de
C Ce qui n’empêche pas d’avoir r(a,b)=r(a,b’)
32/55
Contraintes intra relations : dépendence fonctionnelle implicite
1,1
PersonnelidPersonnelnomprenomadresse
0,n
EtablissementidEtablissementnomvillespecialité
affecter
1 membre du personnel est affecté dans 1 seul établissement: affecter(e) ne renvoie qu’une valeur.
La flèche traduit ici une dépendance fonctionnelle de Personnel envers Etablissement
Le personnel ne peut exister sans l’établissement mais l’inverse n’est pas vrai.
Attention : la flèche n’indique donc pas un sens de lecture mais le sens de la dépendance.
CIF
33/55
Contraintes intra relations : dépendance fonctionnelle & relation ternaire
Un enseignant ne fait 1 cours que dans une seule salle (ie la même) En d’autres termes à 1 (enseignant,cours) ne correspond qu’une seule
salle Mais :
Un enseignant peut faire 2 cours différents dans des salles différentes 2 enseignants peuvent faire le même cours dans 2 salles différentes
0,nEnseignant
0,n
Cours
0,nSalle
faire cours
CIF
Note : dans WinDesign CIF = Contrainte d’unicité
34/55
Contraintes intra relations : dépendence fonctionnelle &
relation ternaire
Enseignant Cours Salle Pr Tourne Physique Nuc. Amphi A
Pr Tourne NanoTechno Salle TP
Dr Schnock Physic Nuc. Salle TP
Pr Tourne Physique Nuc. Salle TP
MdC Ornet Chant Salle TD
Traduction Fonctionnelle : Dans le cadre de la relation faire_cours Enseignant x Cours -> Salle (e, c) -> (s)
Donc je ne puis avoir (e, c, s) & (e, c, s’) vrais simultanément (e,c) ne doit être associé qu’à 1 seul s
≠
Incompatible avec CIF ! 2 valeurs ≠ pour 1 même couple de valeurs (Ens, Cours) => Il faut choisir.
35/55
Contraintes inter relations : Exclusivité
L’occurrence d’une relation rend impossible une autre relation
Ex : Un enseignant ne fait qu’enseigner.
1,n
0,n
Enseignant1,n
Cours
0,nEleve
enseigner
noter
IX
36/55
Contraintes inter relations : Simultanéité
L’occurrence d’un relation implique simultanément une autre relation
Ex : Un enseignant note les élèves qui ont suivi le cours … durant le cours.
1,n
0,n
Enseignant1,n
Cours
0,nEleve
enseigner
noter
IS
37/55
Contraintes inter relations : Totalité
L’occurrence de l’entité participe à au moins 1 des deux relations
Ex : Un enseignant soit note, soit fait le cours, soit les 2
1,n
0,n
Enseignant1,n
Cours
0,nEleve
enseigner
noter
IT
38/55
Contraintes inter relations : Inclusion
Si l’occurrence de l’entité participe à 1 relation, alors elle participe à l’autre (mais pas réciproquement)
Ex : Un enseignant doit noter son cours, mais rien n’empêche qu’un enseignant donne des notes à un élève.
1,n
0,n
Enseignant1,n
Cours
0,nEleve
enseigner
noter
II
3. Le cas X
MCD
40/55
MCD Simple Actuel
41/55
MCD Evolué Actuel
42/55
MCD Futur
43/55
MCD Examen Rattrapage
Il ne s’agit qu’une piste de correction.
Evidemment développable à souhait => entités
Modèle, Marque, Catégorie véhicule, avec relations
spécifiques avec consom-mables et pièces voire
prestation (prix variable selon catégorie…)
Généralisation possible, spécialisation aussi
(Consommable & Pièce étant des entités « filles »
Notamment si on développe l’entité Véhicule
44/55
Exemple de problèmes de modélisation : énoncé Un client passe commande de produits
auprès de vendeurs. Chaque produit et chaque vendeur sont localisés dans un rayon et un seul. On en extrait les informations marquées en gras.
45/55
Exemple de problèmes de modélisation : relations Un client passe commande de produits auprès de vendeurs.
Chaque produit et chaque vendeur sont localisés dans un rayon et un seul. On déduit les relations entre les entités
46/55
Exemple de problèmes de modélisation : cardinalités Un client passe commande (suppose plusieurs) de produits (donc
plusieurs) auprès de vendeurs (pas précisé si 1 seul ou plusieurs). Chaque produit et chaque vendeur sont localisés dans un rayon et un seul (mais ne dit pas si plusieurs vendeurs dans un même rayon => hypothèse la plus générale). Un et seul => (1,1), plusieurs => (0,n) ou (1,n)…
= Ligne de commande indique la quantité commandée
S’il y a plusieurs vendeurs dans un rayon, on ne sait pas qui a vendu le produit (tout au plus a-t-on une
liste de vendeurs potentiels)
47/55
Ajout d’hypothèses …
On veut savoir qui a vendu quoi… pas assez précis car on ne sait pas si TOUS les produits
doivent avoir un et un seul vendeur… soit en d’autres termes, est ce qu’il y a exclusivité ou est ce que plusieurs vendeurs ont le droit de vendre le même produit …
… et cela a un impact sur la modélisation. Différentes hypothèses
Cas le plus « simple »1 on ne précise rien et tout est possible : un même produit vendu par plusieurs vendeurs (vente faite en 2x, le client revient sur ses pas et demande à nouveau le même produit mais trouve un autre vendeur)
Cas où chaque produit à un seul vendeur Cas où le rayon a un seul vendeur
1. Plus simple en ce sens qu’il n’y a pas d’hypothèse restrictive, mais pas forcément plus simple en terme de modélisation
48/55
Cas 1 : un même produit vendu par plusieurs vendeurs
Qui des cardinalités ? Il faut réfléchir sur la relation … et comprendre ce qu’elle
signifie …
49/55
Cas 1 : un même produit vendu par plusieurs vendeurs => cardinalités…
La relation traduit le fait que des exemplaires/ instances des entités Commande, Produit et Vendeur vont être en relation => triplet (c1, v1, p1, 2) signifiant => la commande c1 a eu 2 exemplaires du produit p1
vendus par le vendeur v1 Définir les cardinalités d’une relation ternaire c’est définir,
l’obligation ou non des instances des entités (p1, p2 pour Produit) de participer à la relation Contenir… Si on met 1..n au niveau de la patte reliant à la commande
cela signifie que toute commande créée doit participer au moins 1 fois à la relation… qui incidemment précise combien de produits (entre autre) ont été vendu.
Si on met 0..n au niveau de la patte reliant le vendeur à la relation, cela signifie qu’1 vendeur peut ne jamais participer à la relation … et donc n’avoir jamais vendu de produits.
50/55
Cas 1 : un même produit vendu par plusieurs vendeurs => conséquences «instances»
La relation peut être représentée par les valeurs suivantes : (c1, v1, p1, 2)
(c1, v2, p1, 1) (c1, v1, p3, 2) (c2, v2, p1, 3) (c3, v3, p4, 5)
Toute instance de Commande doit apparaître au moins 1 fois dans la relation contenir
=> si j’ajoute une commande c5 => j’aurai forcément quelque chose comme (c5, v?, p?, quantités) au moins 1 fois….
Par contre, un produit peut ne jamais apparaître dans la relation indiquant qu’il n’a jamais été vendu …
51/55
Cas 1 : un même produit vendu par plusieurs vendeurs. Analyse critique de la solution
Inconvénient de cette solution : Chaque ligne de commande devant avoir un vendeur, on ne peut
ajouter de produits « libre service » … càd vente sans intermédiaire d’un vendeur …
« On veut savoir qui a vendu quoi… » signifie que si quelque chose a été vendu via un vendeur, on veut le savoir (pour pouvoir calculer la prime d’intéressement mesurée en Chiffre d’Affaires individuels par exemple)…
…. MAIS cela ne veut pas dire que tous les produits ont un vendeur … la réciproque n’est pas automatique… (cf. cours de philosophie de terminale)
C’est une subtilité qui a un impact sur la conception … Solution 1 : apportée au niveau de la mise en œuvre du SI
On peut créer un vendeur «inconnu » càd ajouter un instance « inconnu » dans les exemplaires de l’entité Vendeur, qui ne correspond à personne en réalité;
Une commande sans vendeur sera donc affectée à ce vendeur fictif Ex : (c6, ‘inconnu’, p8, 5)
L’opération devra être faite automatiquement (par la caisse par exemple…)
52/55
Solution 2 : Ajouter une deuxième relation Commande Produit sans vendeur … … mais alors on doit lever l’obligation de vente avec vendeur en
modifiant la cardinalité entre commande & Contenir
Cas 1 : un même produit vendu par plusieurs vendeurs. 2ème solution alternative
Relation Contenir sans vendeur => un produit ne devrait apparaître qu’une seule fois par
commande
Solution précédente maintenue pour les cas de ventes avec
vendeur
Relâchement de la contrainte 1..n =>
0..n car on peut avoir une commande
sans vendeur
Contrainte 1.n de Contenir$ remplacée par contrainte
inter-relations. La « Totalité » oblige qu’au moins 1 de ces 2
relations soit instanciée
53/55
On décide de ne mémoriser que le cumul de vente (puisque c’est l’information utile pour calculer la rémunération supplémentaire) => à chaque vente on met à jour le montant pour chaque vendeur (en relation
avec produits comme ici (solution L.P.) ou avec la commande. Ex : si j’ai Contenir(c1, p2) saisie par vendeur v1 alors
CumulVente=CumulVente+1 dans la relation Vendre entre Vendeur et Produit (idéalement il faudrait ajouter une date pour compter chaque jour les ventes… (et maj si commande annulée)
Inconvénient : il faut que cela soit automatisé au niveau du SGBD (trigger par ex) ou de l’IHM qui gère les commandes… => solution « technique »… à chaque ajout de commande, il faudra mettre à jour la valeur de CumulVente pour le vendeur et les produits concernés… Idem si la commande est annulée
Cas 1 : un même produit vendu par plusieurs vendeurs. 3ème solution alternative
54/55
Cas 2 : un même produit vendu par un seul vendeur
=> connaître le produit c’est connaître le vendeur Hypothèse « pédagogique » car dans la pratique cela veut dire que le vendeur est
toujours là (pas de vacances, pas de pause, toujours présent). Autre solution, un produit peut être géré par plusieurs vendeurs, mais à un
instant t, un seul est en charge => dans une même journée plusieurs peuvent se partager la responsabilité => pour calculer la rémunération des vendeurs, on peut se baser sur la date/heure
de la commande et comparer cela à l’emploi du temps des vendeurs (cf. solution suivante)
Alternative : on corrige 1,1 en 1,n et on
ajoute une date début/fin de la responsabilité
dans la relation Gérer
55/55
Cas 3 : un seul vendeur dans un rayon (à un instant t)
Solution qui se rapproche un peu de l’alternative du transparent précédent : Hypothèse : 1 seul vendeur dans un rayon à un instant t. => un produit étant dans un seul rayon, connaître le produit c’est connaître le
rayon donc le vendeur… Pour calculer une rémunération on sélectionnera les périodes durant lesquelles un
vendeur a travaillé et on recherchera toutes les produits commandés à cette date là (suppose jointure entre Commande & Produit).
Planning