Ingénierie des Systèmes d’Information -...

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


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


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


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


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


propose

Cardinalité Min..max

Nom de la relation Et eventuellement propriétés

Dépendance fonctionnelle

proposer

19/55


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


0,n

0,n

EtablissementidEtablissementnomvillespecialité

verser TxAppsomme

etre en relation commerciale

20/55


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


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


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


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


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

Ingénierie des Systèmes d’Information -...

Documents

Transcript of Ingénierie des Systèmes d’Information -...