Bonjour Dominique,
Le modèle que tu proposes répond au besoin. En ce sens, il est correct.
On peut toutefois l'améliorer en considérant qu'une distribution est l'association entre Bénéficiaire, Aliment et Date de distribution.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
[Bénéficiaire]
|
0,n
|
|
[Date_distribution]--0,n----(Distribution)
|
|
0,n
|
[Aliment]
Légende :
-------------
[ENTITE]
(ASSOCIATION) |
La table issue de l'association Distribution aura alors cette définition :
Distribution (Beneficiaire_id, Aliment_id, Distribution_date, quantite)
Deux remarques :
1) J'ai remplacé "aliment_nombre" par "quantite" car la propriété "aliment_nombre" existe déjà dans l'entité Aliment. Or, une propriété conceptuelle doit être unique dans un MCD.
2) Pourquoi l'association Distribution est-elle préférable à l'entité Distribution ? L'association garantit que le triplet {Beneficiaire_id, Aliment_id, Distribution_date} est unique dans la table Distribution. Cette garantie n'est pas fournie par l'entité Distribution. En effet, en l'absence de contrôle programmatique, on pourrait se retrouver avec quantité de doublons dans cette table. Exemples :
Code:
1
2
3
4
5
6
|
Distribution_id Beneficiaire Aliment Date
--------------- ------------ ------- ----------
1 Martin Lait 01-09-2017
2 Martin Lait 01-09-2017
etc. |
Pour éviter ces doublons, il faudrait mettre en place des contrôles avant insertion d'une ligne dans la table.
Avec l'association Distribution, c'est le SGBD qui prend en charge ces contrôle de façon automatique.
