M.E.D.A.L. Module dEnseignement à Distance pour lArchitecture Logicielle Alain VAILLY Diapositive n° 1 Université de NANTES Les paradigmes Le modèle entités-associations-propriétés

M.E.D.A.L.M.E.D.A.L.

Module d’Enseignement à Distance Module d’Enseignement à Distance pour l’Architecture Logiciellepour l’Architecture Logicielle

Alain VAILLYDiapositive n° 1 Université de NANTES

Les paradigmes

Le modèle entités-associations-propriétés (3)


L’usage de ce document, sous quelque forme que ce soit (électronique, papier…), à titre personnel ou devant des étudiants, est autorisé et libre de droits, à la condition expresse qu’il soit conservé dans l’état (et notamment

qu’il comporte la page de garde et cet avertissement).Tout autre usage, notamment commercial, toute diffusion via un serveur

informatique, une liste de diffusion… est soumis à l’accord PRÉALABLE de son auteur.

Ce document constitue un TOUT. Toute coupe, toute modification non autorisée par son auteur sera assimilée à une atteinte aux droits de l’auteur

et poursuivie comme telle devant les tribunaux.

AVERTISSEMENT

MEDALMEDAL

Alain VAILLYDiapositive n° 3

Cours magistral

Contexte

Auto-évaluation

Exercices

Corrigés des

exercices

RéférencesEvaluation

Université de NANTES


Etudes de cas

comportements



Cours magistral

- le modèle E-A-P

- les modèles de traitement de Merise

informations

fonctions

- le modèle relationnel

- les réseaux de PETRI

PLAN

1) Introduction

2) Notions de base

3) Utilisation et modélisation

4) Normalisation des modèles

6) Conclusion

5) Extensions



Cours magistral1) Introduction

2) Notions de base


3) Utilisation et modélisation

6) Conclusion PLAN

2.1) Informations et domaines2.2) Entités et occurrences2.3) Associations2.4) Collections et rôles2.5) Propriétés explicites et implicites2.6) Cardinalités

4.1) Normalisation des noms4.2) Normalisation des propriétés4.3) Normalisation des entités4.4) Normalisation des cardinalités4.5) Normalisation des associations

3.1) Recueil et structuration3.2) Interprétation3.3) Modélisation3.4) Description des modèles

5) Extensions

5.1) Expression des contraintes5.2) Héritage et agrégation5.3) Personnalisation des associations5.4) Association d ’associations


0) Rappels



Déjà vu :

- association,

- identifiant,

- cardinalité,

- ...

- entité,

- propriété,

Encore à découvrir :

- extensions,

- héritage,

- agrégation,

- personnalisation,

- normalisation,

- contraintes,

- ...


0) Rappels



Pour limiter la dispersion de l’attention des étudiants, les exemples utilisés dans cette présentation se

rapportent tous au même contexte, celui d’un marchand de timbres de collection, ayant pour objectifs :

- la gestion de son stock,

- la gestion de sa clientèle,

- la création des catalogues de vente,

ContexteContexte- le suivi des ventes,

- la production de statistiques.


0) Rappels



AVERTISSEMENT : Les informations contenues dans la « base de données » que nous évoquons ont été choisies sur des critères pédagogiques. La philatélie est passée au second plan. Nous

savons, par exemple, parfaitement que les catalogues de vente par correspondance sont beaucoup plus complexes que ceux que nous

avons décrit.

Notre objectif n’est pas de faire de nos étudiants informaticiens de futurs Théodore Champion, mais de les sensibiliser aux problèmes que l’on doit surmonter lorsque l’on conçoit une base de données.

La philatélie n’est, ici, qu’un moyen, aucunement un but.

Contexte (2)Contexte (2)

Théodore Champion, marchand parisien mondialement connu, a fourni au début du siècle les plus grands

collectionneurs. Sa maison existe encore aujourd’hui, plus de cinquante ans après sa mort.

Normaliser, c’est mettre aux normes. Les normes dont il est question visent à atteindre une certaine qualité des schémas

produits.




Il y a des normes pour quasiment chaque élément :

- normalisation des noms,

- normalisation des propriétés,

- normalisation des cardinalités,

- normalisation des associations.

Par contre, une tolérance existe dans le cas où deux éléments de type différent ont le même nom.



4) Normalisation des modèles4.1) Normalisation des noms

La règle à respecter, à ce niveau, est simple :

Pas deux fois le même nom pour le même type d’éléments.Pas deux fois le même nom pour le même type d’éléments.

ASSO2

date

CLIENT

numéro-clientnom-client

adresse-règlementdate

COMMANDE

numéro-commandedate

ANNEE

année

une seule foisune seule fois

Les entités CLIENT et PERSONNE sont, en fait, les mêmes. On les regroupe en une

seule, appelée PERSONNE.




Le non-respect de cette règle est un indicateur d’inachèvement de la modélisation. Il peut (cela n’est pas obligatoirement le cas) y

avoir un regroupement à faire :

CLIENT

numéronom


PROSPECT

numéronom

adressedate

PERSONNE

numéro-personnetype (C, P)

nom-personneadresse-personne

date-personne

Cette association nouvellement créée permet à COMMANDE d’avoir accès à la

propriété enlevée.




Il peut aussi y avoir un travail de mise en évidence d’un lien, d’une association, à entreprendre :

CLIENT


date

adresse

COMMANDE


adresse

CLIENT


date

adresse

COMMANDE


EST-PASSEE-PAR

1, 1




Si la suppression de (n - 1) exemplaires des propriétés ayant le même nom dérange, il est toujours possible de satisfaire la règle en

rendant les noms uniques :

ASSO2

date

CLIENT



COMMANDE


Le contrôle étant essentiellement syntaxique, la norme est respectée !




Si la suppression de (n - 1) exemplaires des propriétés ayant le même nom dérange, il est toujours possible de satisfaire la règle en

rendant les noms uniques :

ASSO2

date-a

CLIENT


adresse-règlementdate-cl

COMMANDE

numéro-commandedate-co

une seule foisune seule fois

Lorsque que l’outil propose un nom externe et un nom interne, l’unicité porte sur ce dernier. Il est donc possible

de trouver des schémas en apparence faux.




Cette norme est mise en œuvre par tous les outils d’aide existant. La raison en est qu’ils utilisent tous un dictionnaire de données

(souvent appelé référentiel) et que l’unicité est vérifiée au niveau de celui-ci.

+schéma

dictionnaire

Pour le dictionnaire, il n’y a aucune ambiguïté. Ce schéma est normalisé. Il n’y a pas deux propriétés ayant le même

nom.




ASSO2

date

CLIENT



COMMANDE


nom interne

DATECL

DATECO

DATEA

nom externe

date

date

date

élément contenant

CLIENT

COMMANDE

ASSO2

Pour le dictionnaire, il y a ambiguïté. Ce schéma n’est pas normalisé. Il y a (au moins) deux propriétés ayant le même

nom.




ASSO2

date

CLIENT



COMMANDE


nom externe

date

date

date

élément contenant

CLIENT

COMMANDE

ASSO2



4) Normalisation des modèles4.1) Normalisation des noms Certains logiciels imposent, en

plus, quelques règles visant à améliorer la lisibilité du schéma :

- chaque entité a pour nom un nom commun singulier.(ex : CLIENT, COMMANDE, TIMBRE…)

- chaque association a pour nom un groupe verbal.(ex : EST-PASSEE-PAR, GARANTIT…)

- chaque propriété a un nom composé de deux mots, le second étant obligatoirement celui de l’entité ou de l’association « dans » lequel il est.

- pas de nom qu’on ne peut trouver dans un dictionnaire(ex : XY, ASSO1, ASSO2…)



4) Normalisation des modèles4.2) Normalisation des propriétés

Plusieurs contrôles peuvent être opérés sur les propriétés. Il y a d’abord la vérification de l’unicité des noms (cf. paragraphe

précédent). Il y a ensuite un travail de détection/correction de propriétés :

- ayant des noms non significatifs,

- redondantes,

- calculées,

- mal localisées.




La redondance des propriétés doit être éliminée des schémas. Sa persistance fait courir à la base de données un risque majeur, celui

de l’incohérence. S’il y a, en effet, à deux endroits différents la même information, lors de la mise-à-jour il ne faudra pas oublier

une occurrence.

E1

prop1

E2

prop1propr1

XYZ

Occurrences de E1

propr1

XYZ

Occurrences de E2

Val (prop1) := ZGH






une occurrence.

E1

prop1

E2

prop1propr1

ZGH

Occurrences de E1

propr1

XYZ

Occurrences de E2

Val (prop1) := ZGH






une occurrence.

E1

prop1

E2

prop1propr1

ZGH

Occurrences de E1

propr1

ZGH

Occurrences de E2

Val (prop1) := ZGH




Plus généralement, on doit « traquer » les propriétés polysèmes, homonymes ou autres synonymes.

nom unique ayant

plusieurs sens (ex : quantité)

plusieurs nom ayant le

même sens (ex : libellé,

description...)

plusieurs noms (éventuellement) se

prononçant et s ’écrivant de la

même façon, et ayant chacun un sens

différent




L’ordinateur est d’abord un super-calculateur. Il a, par contre, un point faible. Il se « déplace » lentement. Il calcule donc beaucoup plus rapidement qu’il ne tourne les pages de sa mémoire. On aura donc tendance à ne pas mémoriser les

informations calculées, mais les informations brutes.

info1

info2

info3

info4 := f (info1, info2, info3)info4 := f (info1, info2, info3)

Si les propriétés info1, info2, info3 sont disséminées, le calcul sera rapide, mais

les temps d’accès seront plus longs.

Faut-il alors mémoriser info4 ? NONNON




La vraie raison qui justifie la non-mémorisation d’une information calculée réside dans le risque d’incohérence

encouru lors d’une modification d’une valeur brute.

info1

info2

info3


Supposons que l’on ait, malgré tout, enregistré info4 et que la valeur de info3 change.

info4





encourue lors d’une modification d’une valeur brute.

info1

info2

info3bis



info4

Si la modification n’est pas répercutée sur info4, il y a incohérence. Le re-

calcul systématique supprime ce risque.





encourue lors d’une modification d’une valeur brute.

info1

info2

info3bis



info4bis

Si la modification n’est pas répercutée sur info4, il y a incohérence. Le re-

calcul systématique supprime ce risque.




Le dernier contrôle porte sur la localisation des propriétés et plus précisément sur le cas d’une association porteuse

d’information(s) de type fonction totale :

Une telle association ne peut garder les Une telle association ne peut garder les informations qu’elle porte. Celles-ci informations qu’elle porte. Celles-ci

sont aspirées par l’entité.sont aspirées par l’entité.

RUBRIQUE1

nom-rubrique1

EST-INCLUSE-DANS

date1, 1

=




Le dernier contrôle porte sur la localisation des propriétés et plus précisément sur le cas d’une association porteuse

d’information(s) de type fonction totale :

Une telle association ne peut garder les Une telle association ne peut garder les informations qu’elle porte. Celles-ci informations qu’elle porte. Celles-ci

sont aspirées par l’entité.sont aspirées par l’entité.

EST-INCLUSE-DANS

1, 1

RUBRIQUE1

nom-rubrique1

date




La raison principale de cette norme tient à la notion de contenant, de conteneur, et au fait qu’à terme il ne doit plus en rester qu’un seul. Les propriétés aspirées peuvent être soit dans

l’entité, soit dans l’association.

Dans la mesure où l’on veut réduire le nombre de conteneurs, alors on procède au déplacement.

RUBRIQUE1

nom-rubrique1

EST-INCLUSE-DANS

date1, 1

EST-INCLUSE-DANS

1, 1

RUBRIQUE1

nom-rubrique1

date

2 conteneurs 1 conteneur




nom-rubrique1 date

ALPHA date1

GAMMA date2

BETA date3

nom-rubrique1

ALPHA

BETA

GAMMA

RUBRIQUE1

nom-rubrique1

EST-INCLUSE-DANS

date1, 1

BETA date1DELTA

EST-INCLUSE-DANS

1, 1

RUBRIQUE1

nom-rubrique1

date

RUBRIQUE1 EST-INCLUSE-DANS

nom-rubrique1

ALPHA

GAMMA

BETA

date

date1

date2

date3

RUBRIQUE1



4) Normalisation des modèles4.3) Normalisation des entités

Il y a peu de choses à vérifier relativement aux entités. Une règle doit absolument être respectée, celle ci-dessous,

concernant les identifiants.

Toutes les entités doivent avoir un identifiant.Toutes les entités doivent avoir un identifiant.

CLIENT



CLIENT

numéro -clientnom-client

adresse-règlementdateX

Cela est, en général,

contrôlé par les outils d’aide.



4) Normalisation des modèles4.3) Normalisation des entités

Il est nécessaire de passer en revue les schémas et d’analyser soigneusement les entités réduites aux seules propriétés

identifiantes.

ANNEE

année

1) peut-on l’avoir ailleurs ?

2) sert-elle de point d’accès ?

Celles-ci pouvant souvent être récupérées (parmi les propriétés identifiantes des associations dans lequelles ces entités sont impliquées), il faut se poser la question de la

survie de ces entités.



4) Normalisation des modèles4.4) Normalisation des cardinalités

Les cardinalités mini et maxi appartiennent à l’ensemble {0, 1, n}. Les cardinalités mini et maxi appartiennent à l’ensemble {0, 1, n}. Toutes les valeurs en dehors de celui-ci sont à proscrire.Toutes les valeurs en dehors de celui-ci sont à proscrire.

La formulation ci-contre est meilleure.

Mettre un maximum de 3 limitera à 3 le nombre de

liaisons et ce sur la totalité de la vie de l’occurrence de E1.

ASSO

0, 3

E1

ASSO

0, n

E1

(n ≤ 3)



4) Normalisation des modèles4.4) Normalisation des cardinalités

Pas plus de 3 ==> structure de taille fixée à 3 éléments… si, un jour, cela passe à 5

… il faut tout refaire.

ASSO

0, 3

E1



4) Normalisation des modèles4.5) Normalisation des associations

Trois « choses » sont à vérifier, concernant les associations :

fantômes

décomposables redondantes

ASSO

1, 1

E1

1, 1

E2

ASSO

-, n

E1

1, 1

E2

E3

- , n

1, 1

ASSO1

-, -

E1

1, 1

E2

E3

- , -

ASSO2 ASSO3

1, 1




Une association fantômefantôme est une association dans laquelle tous les

couples de cardinalités (mini, maxi) sont à (1, 1).

Chaque occurrence de chaque entité

appartenant à la collection de

l’association est impliquée une et une

seule fois.

1, 1

ASSO

E1

1, 1

E2

E31, 1

1, 1

E4

card (E1) = card (E2) = card (E3) = card (E4)card (E1) = card (E2) = card (E3) = card (E4)




Une telle structure se simplifie.

1, 1

ASSO

E1

1, 1

E2

E31, 1

1, 1

E4

Il y a 4 clés potentielles. Il faut en choisir une.

E1-2-3-4

ident-E1ident-E2ident-E3ident-E4prop-E1prop-E2prop-E3prop-E4

1, 1

ASSO1

-, -

E1

1, 1

E2

E3

- , -

ASSO2 ASSO3

1, 1

- , -




Il y a redondance de cheminsredondance de chemins si pour chaque occurrence de

l’entité de départ, que l’on parte sur la gauche ou sur la droite, on arrive à la même occurrence de

l’entité d’arrivée.

départ

arrivée

Si on est dans cette situation, on va supprimer le plus court

chemin (le plus « pauvre »).

X




départ

arrivée

a E1, X (a) = Y (a)

Soient :- Ei l’ensemble des occurrences de l’entité Ei,- X le chemin de gauche,- Y le chemin de droite.

1, 1

ASSO1

-, -

E1

1, 1

E2

E3

- , -

ASSO2 ASSO3

1, 1

- , -

NB : pour passer cette partie Approfondissement, cliquer sur la loupe.




départ

arrivée

X : ASSO3 o ASSO1

Soit Ai l’ensemble des occurrences de l’association ASSOi.

A1 : {x E1, y E2, tq ASSO1 (x) = y}

a E1, ASSO3 (ASSO1 (a)) = ASSO2 (a)

Y : ASSO2

1, 1

ASSO1

-, -

E1

1, 1

E2

E3

- , -

ASSO2 ASSO3

1, 1

- , -

NB : pour passer cette partie Approfondissement, cliquer sur la loupe.




Si tous les clients règlent eux-même leurs factures, il y a redondance. On doit donc enlever PAYE (le plus court chemin).

1, 1

CORRESPOND-A

-, -

REGLEMENT 1, 1

FACTURE

CLIENT

- , -

PAYE

EST-RECUE-PAR

1, 1

- , -

Cette combinaison de cardinalités est une condition nécessaire pour

qu’il y ait redondance.




Il y a deux cas de décomposition d’associations n-aires, avec n > 2.

La première concerne une association analogue à celle ci-contre, dans

laquelle il y a au moins un couple de cardinalités

(1,1) ou (0, 1).

ASSO

-, n

E1

1, 1

E2

E3

- , n




La règle est simple :

décomposable

ASSO

-, n

E1

-, 1

E2

E3

- , n

NON décomposable

ASSO

-, n

E1

-, n

E2

E3

- , n




… son application aussi simple :

AVANT

ASSO

-, n

E1

-, 1

E2

E3

- , n

APRES

ASSOa

-, n

E1

-, 1

E2

E3- , nASSOb

-, 1




APRES

ASSOa

-, n

E1-4

1, 1

E2

E3- , nASSOb

1, 1

ASSO

-, n

E1

1, 1

E2

E3

- , n

E4

1, 1

Ca marche aussi avec plus de 3 pattes ...

AVANT




AVANT

ASSO

-, n

E1

1, 1

E2

E3

- , n

E4

1, 1

Il est toujours possible de transformer une

association en entité.

-, nE1

1, 1

E2

E3

- , n

E4

1, 1ASSO

1, 1

1, 11, 1

1, 1






-, nE1

1, 1

E2

E3

- , n

E4

1, 1ASSO

1, 1

1, 11, 1

1, 1

Toute cette partie est simplifiable (on peut tout

réunir en une seule entité).






-, nE1

1, 1

E2

E3

- , n

E4

1, 1ASSO

1, 1

1, 11, 1

1, 1

ASSOa

-, n

E1-4

1, 1

E2

E3- , nASSOb

1, 1

ASSOa

-, n

E1-4

1, 1

E2

E3- , nASSOb

1, 1




CQFD !

ASSOa

-, n

E1-4

1, 1

E2

E3- , nASSOb

1, 1

APRES




L’autre cas de décomposition est celui d’une association nn-aire porteuse d’une contrainte d’intégrité

fonctionnelle (CIF) impliquant n-1n-1 entités.

Cette notion de CIF n’ayant pas encore été abordée (elle le sera dans le prochain paragraphe), cette

décomposition ne sera pas décrite ici.



A suivre :

- contraintes ensemblistes,

- contraintes procédurales,

- association d’associations,

- personnalisation d’associations,

- héritage,

- agrégation,

- ...

Entracte (ter)


Bibliographie (sommaire)



Pour compléter la formation ...

la référence :-)

• P. ANDRE, A. VAILLY, « Conception des systèmes d’information ;Panorama des méthodes et des techniques », Editions Ellipses, janvier 2001,ISBN 2-7298-0479-X

• D. NANCI, B. ESPINASSE, « Ingéniérie des systèmes d’information : Merise ; deuxième génération », 4e édition, Editions Vuilbert, 2001, ISBN 2-7117-8674-9

Documents

M.E.D.A.L. Module dEnseignement à Distance pour lArchitecture Logicielle Alain VAILLY Diapositive n° 1 Université de NANTES Les paradigmes Le modèle entités-associations-propriétés