Bonsoir,
Envoyé par
JPhi33
L'association Récolter doit associer l'entité Récolte à l'association Placer et non pas à l'entité Ruche.
( Placer )--1,1----( Récolter )----0,n->[ Récolte ]
Bien vu. Cette solution est évidemment préférable à celle du "triangle" associatif Placer/Récolter/Situer, laquelle, comme vous le faites remarquer, autoriserait la récolte du miel de ruches absentes des emplacements où l’on récoltera.
Une remarque toutefois concernant le niveau logique, en l’occurrence la structure des tables et leur manipulation. Lors du passage du MCD au MLD, l’association-type Récolter devra faire l’objet de la génération d’une table Récolter (ayant une clé de structure identique à celle de la table Placer). En effet, à supposer que l’on sache tout sur une récolte (table Récolte), pour leur part, le poids et la date de la récolte par ruche ne seront de toute façon pas connus tant que cette récolte n’aura pas eu lieu. Si la table Placer absorbait la table Récolter, les attributs correspondants (disons PoidsRec et DateRec) devraient être marqués NULL ou héberger des valeurs spéciales, provisoires, en attendant que la récolte ait lieu. Ceci introduirait des lourdeurs et des risques d’erreur dans la manipulation des données (instruction SQL SELECT).
Envoyé par
JPhi33
Envoyé par
Jérémy31
On enregistre pour chaque ruche la date et le poids récolté.
L'endroit où se situent ces informations ne peut donc pas être l'entité Récolte. La date de récolte et le poids récolté doivent être des propriétés de Placer qui, selon la modélisation décrite dans mon précédent message, est une association entre Ruche, Emplacement et Période.
Comme je viens de l’écrire, l’association-type Récolter devrait de préférence faire l’objet d’une table lors du processus de dérivation du MCD en MLD. Ainsi, on peut ne valoriser la table Recolter qu’une fois la récolte effectuée. La représentation tabulaire graphique devrait ressembler à ceci (Power AMC) :
Recolter.jpg)
Dans cette représentation, j’ai implicitement défini un type EmpPeriode pour l'attribut du même nom, mais on peut préférer remplacer ce dernier par une paire {DateDebut, DateFin}.
Envoyé par
JPhi33
Quel que soit le type d'identification utilisé, il y aura lieu, dans l'application informatique, de mettre en oeuvre des contrôles de non chevauchement des périodes pour une ruche donnée.
Certes, mais ces contrôles de non chevauchement doivent être pris directement en charge par le SGBD et surtout pas par les programmes, c'est-à-dire que dès que l’on crée ou modifie une date, le contrôle devra être automatiquement déclenché par le SGBD. La norme SQL propose en ce sens l’instruction CREATE ASSERTION, mais si le SGBD ne la propose pas, on peut mettre en œuvre un trigger (c'est plus lourd, mais ça marche bien).
Exemple (non testé) d’assertion :
1
2
3
4
5
6
7
|
CREATE ASSERTION Rx CHECK (NOT EXISTS (
SELECT x.CodeRuche
FROM Placer x, Placer y
WHERE x.CodeRuche = y.CodeRuche
And (x.CodeEmp < y.CodeEmp Or x.CodeEmp = y.CodeEmp And x.DateDebut < y.DateDebut)
And x.DateFin >= y.DateDebut And x.DateDebut <= y.DateFin)) ; |
Pour un exemple de trigger de test de non recouvrement des dates, voir ici.
Envoyé par
JPhi33
L'alternative est de faire de Placer (ou de Récolter) une association ternaire entre Ruche, Emplacement et Récolte mais cette option comporte des inconvénients :
- perte sémantique : une seule association pour exprimer 2 concepts
- dénormalisation : l'association ne serait pas en BCNF (dans le modèle relationnel, on pourrait dire que c'est à cause de la présence de la dépendance fonctionnelle {CodeR, CodeEmp} -> {CodeRec} )
Permettez-moi de ne pas être d’accord en ce qui concerne le respect de la BCNF (Jérémy, ne vous sentez pas obligé de suivre, je vais devoir faire un peu de théorie et sortir du périmètre de votre étude). Passons donc au niveau relationnel et intéressons-nous à la relation Placer (le terme relation étant pris au sens de la théorie relationnelle), issue par dérivation de l’association-type Placer considérée comme ternaire et qui a absorbé au passage la relation Récolter. L’en-tête de la relation Placer est le suivant :
{CodeR, CodeEmp, CodeRec, PoidsRec, DateRec}
En-tête dans lequel les attributs PoidsRec et DateRec représentent respectivement le poids et la date de récolte du miel d’une ruche donnée, attributs absorbés en même temps que la relation Récolter. Je fais abstraction de l’attribut HistoriqueEmp qui n’est pas pertinent en l’état et dont l’absence n’influe pas sur ce qui suit.
Un AGL déclarera le trio {CodeR, CodeEmp, CodeRec} comme étant clé de la relation Placer, mais ceci est une erreur.
Avant d’aller plus loin, je suis obligé de rappeler quelques définitions. Je commence par celle de la clé (plus précisément candidate) :
Une clé candidate est un sous-ensemble d’attributs K de l’en-tête d’une relation R, respectant les deux contraintes suivantes :
Unicité. Deux tuples distincts de R ne peuvent avoir même valeur de K.
Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.
Une surclé est un sous-ensemble d’attributs K de l’en-tête d’une relation R, astreint à respecter seulement la contrainte d’unicité. (La clé candidate peut être vue comme une spécialisation de la surclé).
Le trio {CodeR, CodeEmp, CodeRec} constitue une surclé, mais certainement pas une clé candidate, car s’il respecte la contrainte d’unicité, il ne respecte pas la contrainte d’irréductibilité, ceci à cause de la dépendance fonctionnelle dont vous avez fait mention ci-dessus :
DF01 : {CodeR, CodeEmp} → {CodeRec}
Qui signifie que (dans un contexte intemporel), une ruche située à un emplacement donné ne peut faire l’objet que d’une récolte.
Il existe d’autres dépendances fonctionnelles. En effet (toujours dans un contexte intemporel), la récolte d’une ruche donnée ne peut se faire qu’à un seul emplacement :
DF02 : {CodeR, CodeRec} → {CodeEmp}
En outre, puisque selon l’énoncé initial « On enregistre pour chaque ruche la date et le poids récolté », il existe les dépendances fonctionnelles
DF03 : {CodeR, CodeRec} → {PoidsRec}
DF04 : {CodeR, CodeRec} → {DateRec}
En appliquant la règle d’augmentation (voir les axiomes d’Armstrong) appliquée à DF01, on produit :
DF05 : {CodeR, CodeEmp} → {CodeR, CodeRec}
Et par transitivité appliquée à DF05 et DF03 :
DF06 : {CodeR, CodeEmp} → {PoidsRec}
Même principe avec DF04 :
DF07 : {CodeR, CodeEmp} → {DateRec}
Si l’on applique la règle de réflexivité (axiomes d’Armstrong), on produit les DF :
DF08 : {CodeR, CodeRec} → {CodeR}
DF09 : {CodeR, CodeRec} → {CodeRec}
DF10 : {CodeR, CodeEmp} → {CodeR}
DF11 : {CodeR, CodeEmp} → {CodeEmp}
Autrement dit, il existe les dépendances fonctionnelles suivantes, auxquelles participent l’ensemble des attributs de la relation :
DF12 : {CodeR, CodeRec} → {CodeR, CodeRec, CodeEmp, PoidsRec, DateRec}
DF13 : {CodeR, CodeEmp} → {CodeR, CodeRec, CodeEmp, PoidsRec, DateRec}
Ce qui revient à dire que les paires {CodeR, CodeRec} et {CodeR, CodeEmp} sont clés candidates (et l’on montre que ce sont les seules, en partant du principe qu’une récolte et un emplacement concernent plus d’une ruche).
Je dois rappeler au passage la définition de la dépendance fonctionnelle triviale :
Soit R une relation et X et Y deux sous-ensembles quelconques d’attributs de l’en-tête de R. La dépendance fonctionnelle X → Y est dite triviale si Y est inclus dans X (inclusion ensembliste, au sens large).
Je rappelle enfin la définition de la BCNF :
Une relation R est en forme normale de Boyce-Codd (BCNF) si et seulement si les seules dépendances fonctionnelles non triviales auxquelles elle satisfait sont de la forme X → Y, où X représente une surclé et Y un sous-ensemble d’attributs de l’en-tête de R.
Les seules dépendances fonctionnelles non triviales de la relation Placer sont celles qui ont été énumérées ci-dessus (DF01 à DF07) et les déterminants (parties gauches) de ces DF sont des clés candidates, donc a fortiori des surclés : la relation Placer vérifie la BCNF.
Envoyé par
JPhi33
L'association Placer contient une faiblesse : une Ruche, dans toute sa vie de ruche, ne peut pas se trouver plus d'une fois au même Emplacement. Il faut associer une période à Placer. Cette association devient "tripatte" en associant donc les 3 entités Ruche, Emplacement et Période.
En effet. Maintenant, toujours dans l'intérêt des manipulations SQL, il faudrait peut-être encore distinguer ce qui est en cours de ce qui est historisé.
Une ruche est actuellement à tel emplacement : établir une association-type avec Emplacement à cet effet.
Une ruche a pu précédemment être à tel ou tel emplacement : on retrouve l’association-type Placer.
La barre est montée d’un cran : Jérémy peut préférer éviter les migraines et ne pas faire tout de suite cette distinction.
Pour en revenir à l’exercice ayant trait au respect de la BCNF : les clés candidates de la relation Placer, ainsi que les dépendances fonctionnelles associées, sont à aménager pour prendre en compte la dimension temporelle.
Ainsi, la paire {CodeR, CodeEmp} n’est plus clé. Il faut aussi tenir compte des contraintes : à une date donnée (attribut EmpPeriode), une ruche est à un seul emplacement et fait à cette date l’objet d’une seule récolte. Cela revient à dire que la relation a pour clé la paire {CodeR, EmpPeriode).
permettre la traçabilité d'une récolte
Répondre avec citation
).
Les 
CinePhil_1.jpg)
CinePhil_2.jpg)
CinePhil_3.jpg)
Partager