Questions

Correction sujet n° 1 : Commentaires sur un Schéma Entité/Association


Particularité du sujet :
Ce sujet a pour objet de permettre aux étudiants de percevoir ce que
sont les notions d'entité, d'association et de cardinalité au travers
d'un exemple concret et de dessins.




Soit le Schéma Entité/Association suivant :


[pic]





a) Expliquer le schéma Entité/Association ci-dessus ; notamment la place
des quantités commandées et des quantités en stock. Expliciter les noms
des rôles.

Ce schéma modélise l'activité d'une entreprise qui vend des produits
répartis dans des dépôts. Chaque type de produit est stocké dans un dépôt
unique. Un dépôt peut contenir différents types de produits. On enregistre
pour chaque produit la quantité dont on dispose en stock dans le dépôt.
L'entreprise a plusieurs clients qui lui émettent des commandes. Bien
entendu, un client peut émettre plusieurs commandes (dans le temps). Par
contre, chaque commande concerne un seul client. Une commande est
identifiée par un numéro et comporte une date de livraison et l'adresse de
livraison choisie par le client. De plus, sur chaque commandes figurent des
lignes de commandes. Chaque ligne de commande met en relation la commande
avec un des produits commandés. La quantité commandée est précisée à cet
endroit là car pour un même produit elle peut varier d'une commande à
l'autre.

Ce shéma Entité/Association peut aussi être commenté à partir du dessin ci-
dessous.

[pic]
Dépôts contenant des Produits Commandes
Clients


b) Si on avait eu la cardinalité (1,N) au lieu de (1,1) entre la classe
d'entités produits et la classe d'associations Entreposer, que cela
signifierait-il ? Est-ce cohérent ?

Cela signifierait qu'un même type de produit peut être entreposé dans
plusieurs dépôts.
Cette hypothèse est tout à fait envisageable, mais dans ce cas le schéma
tel qu'il est comporte une petite incohérence. En effet on connaît la
quantité globale que l'on a en stock pour un article donné, mais on ne sait
pas quelle quantité est stockée dans chaque dépôt.
Pour que le schéma reste cohérent, il faut déplacer la propriété
QuantitéStock dans l'association entreposer. La quantité globale que l'on
a en stock pour un article donné peut être calculée en faisant la somme des
valeurs de la propriété QuantitéStock pour tous les liens de l'association
entreposer partant de l'article en question.

c) Si on avait eu la cardinalité (1,N) au lieu de (1,1) entre la classe
d'entités commandes et la classe d'associations Passer, que cela
signifierait-il ? Est-ce cohérent ?

Cela signifierait qu'une même commande peut être émise par plusieurs
Clients. Cette hypothèse n'est pas envisageable et correspond à une erreur
de modélisation.


Correction sujet n° 2 : Les historiques dans un Schéma Entité/Association




Particularité du sujet :
Ce sujet permet d'explorer de façon dirigée certaines subtilités de la
modélisation Entité/Association comme la gestion d'historiques, les
associations réflexives, plusieurs associations entre les mêmes
entités, la notion d'association redondante et l'expression de
contraintes. Les étudiants sont sensés avoir produit au moins un
schéma E/A avant de faire ce sujet.



Soit le Schéma Entité/Association suivant :


[pic]


Quelle est la contrainte imposée par le schéma précédent ?


Un produit ne peut être fabriqué que par une seule usine.

Comment supprimer cette contrainte ?


Transformer la cardinalité (1,1) entre Produits et fabrication en une
cardinalité (1,n) et déplacer la propriété Quantité fabriquée dans
l'association fabrication (sinon on ne connaît pas la quantité fabriquée
par une usine donnée).

Subsiste-t-il des contraintes dans votre nouveau schéma ?


Oui, il ne peut y avoir qu'un seul lien entre un produit et une usine
donnés : si le même produit a été fabriqué plusieurs fois dans la même
usine, on ne peut détailler les différentes quantités fabriquées à chaque
fois. La clé de ce lien unique est (Code Produit, Numéro Usine).

Modifier le schéma précédent de sorte à permettre la gestion d'un
historique des quantités fabriquées.


L'intérêt de la gestion d'un historique dans ce cas est de permettre de
mémoriser la quantité fabriquée à chaque fois que qu'une usine fabrique un
produit donné. Pour cela, on introduit une date qui vas permettre de
distinguer les différents liens pouvant exister entre un produit et une
usine donnés. Ainsi, l'identifiant du lien sera (Code Produit, Numéro
Usine, Date). Cette date peut être insérée soit sous la forme d'une
propriété dans l'association fabrication en précisant que cette propriété
fait parti de la clé. La solution officielle dans la méthode Merise est de
créer une entité date avec pour unique propriété la date (déclarée comme
clé primaire) et à relier cette nouvelle entité à l'association fabrication
avec une cardinalité (0,n). Nous préconisons la première solution car elle
permet de simplifier le schéma.

Solution 1 :

[pic]

Solution 2 :

[pic]

Compléter le schéma pour représenter le fait :


. qu'une usine peut ne pas fabriquer tous les produits dont elle a
besoin ; dans ce cas, elle doit s'approvisionner à l'extérieur ;


. les produits peuvent entrer dans la fabrication d'autres produits.


[pic]

Ce schéma est instructif pour les deux raisons suivantes :
. Il montre qu'il est possible d'avoir plusieurs associations ayant une
signification différente entre les mêmes entités ;
. Il montre qu'une entité peut être en association avec elle même
(association réflexive).

Ce schéma modélise pour chaque usine la liste des produits dont elle a
besoin. Etant donné que l'on connaît pour chaque usine la liste des
produits qu'elle fabrique, on peut en déduire la liste des produits qu'une
usine doit s'approvisionner à l'extérieur. On peut aussi déduire la liste
des usines auprès desquelles une usine peut s'approvisionner.

Ce schéma modélise aussi pour chaque produit, la liste des produits entrant
dans sa fabrication. On peut déduire de l'association correspondante, la
liste des produits fabriqués à partir d'un produit donné.

Considérons l'hypothèse selon laquelle une usine n'a pas besoin d'autres
produits que ceux qui entrent dans la fabrication des produits qu'elle
fabrique. Dans ce cas, l'association avoirBesoin peut être déduite des
associations fabrication et entreDansFabrication. Ainsi l'association
avoirBesoin est redondante et peut être supprimée du schéma.

Le schéma ci-dessus ne modélise pas les usines auprès desquelles une usine
s'approvisionne effectivement, ni (à fortiori) l'historique des
approvisionnements d'une usine en produits. C'est ce que fait le schéma ci-
dessous, en considérant l'hypothèse selon laquelle une usine n'a pas besoin
d'autres produits que ceux qui entrent dans la fabrication des produits
qu'elle fabrique.

[pic]

a) Comment modélise-t-on des contraintes dans un schéma
Entité/Association ? Est-il possible de modéliser toutes les
contraintes ?

Les contraintes que l'on peut modéliser dans un schéma
Entité/Association sont les contraintes de cardinalité et les contraintes
de domaine:

Prenons l'exemple de la cardinalité (1,1) qu'il y avait entre produit et
fabrication dans la première version du schéma. Le 1 de la cardinalité min
spécifie que l'on ne pourra pas stocker de produits qui ne sont pas
fabriqués par une usine répertoriée dans la base de données. Le 1 de la
cardinalité max spécifie qu'un produit ne peut être fabriqué que par une
seule usine.

'QuantitéFabriquée : entier positif' est une contrainte de domaine qui
précise que la valeur d'une quantité fabriquée doit toujours être positive
et entière. Bien souvent, les domaines des propriétés ne sont pas
mentionnés sur le schéma Entité/Association afin d'alléger le schéma. Dans
ce cas le schéma doit être accompagné d'un dictionnaire des propriétés sur
lequel figurent toutes les propriétés classées par Entités puis par
Associations avec leur domaine, éventuellement leur signification et la
taille occupée par une instance.

Certaines contraintes sont sous-jacentes, il s'agit des contraintes
d'intégrité référentielle. Par exemple une usine ne peut pas produire un
produit qui n'existe pas et vice versa. Ces contraintes seront vues en
détail ultérieurement.

Certaines contraintes ne peuvent pas être exprimées sur un schéma
Entité/Association. Par exemple, une usine ne peut pas approvisionner une
autre usine avec des produits qu'elle ne fabrique pas. Cette contrainte
exprime le fait que certains liens de l'association approvisionner sont
possibles sur le plan informatique, mais n'ont pas de sens dans la réalité.
Une telle contrainte doit être exprimée en claire dans le dossier
accompagnant de schéma Entité/Association. Elle pourra être contrôlée par
programmation lors de l'insertion de valeurs dans la base de donnée.

Correction sujet n° 3 : Société Française d'Archéologie


Particularité du sujet :
Ce sujet permet de produire rapidement un premier schéma E/A.
L'intérêt de ce sujet est de laisser les étudiants inventer leur
propre histoire concernant la Société Française d'Archéologie. Le but
est de permettre d'assimiler le lien entre l'histoire que l'on veut
modéliser (monde réel, cahier des charges) et le modèle