Discussion :

[othmanus]

Bonsoir,

Je me suis beaucoup documenté sur ce forum et internet avant de poster, mais je suis dans l'obligation de poser mes soucis en espérant retrouver de l'aide.

Donc voila, je développe une application pour la gestion des ressources en eau des barrages. Rien de compliqué, voici se que j'ai à faire : Gérer les données des volumes annuels et mensuels.

UN barrage a plusieurs Quotas Annuels.
UN barrage + UNE année = UN SEUL Quota Annuel.

UN barrage a plusieurs Quotas Mensuels.
UN barrage + UN mois = UN SEUL Quota Mensuel.

Sachant qu'un quota annuel veut dire : le volume annuel demandé pour l'eau potable, le volume annuel demandé pour l'irrigation, le volume annuel accordée pour l'eau potable, le volume annuel accordé pour l'irrigation. (Même chose pour un quota mensuel.)

Sachant aussi que ces quotas sont des données à saisir, non à calculer.

1- Suis-je obligé de créer des tables "Année" et table "Mois" ? (autrement dit : est-ce qu'il n'y a pas une possibilité de les gérer avec le type DATE ?)

2- Dois-je créer une table "Quota Annuel" avec son ID, une autre pour "Quota Mensuel" puis trouver les associations possible, ou bien mettre les informations (des volumes) dans la table de jointure entre "Barrage" et "Année" (pour le QA) et entre le "Barrage" et "Mois" (pour le QM) ?

Ci-joint les deux MPD réalisés pour chaque cas.

J'espère que c'est assez clair, toutefois, si vous avez des questions n'hésitez pas, et merci d'avance pour votre aide.

[fsmrel]

Bonsoir,


Dans un 1er temps, faisons au plus simple :




Si l’attribut mois (table QuotaMensuel) dépend aussi de l’année, on peut ajouter un attribut Annee participant à la clé de la table.

Afin d’éviter la présence du bonhomme Null, c'est-à-dire si les quotas accordés ne sont pas encore connus, les attributs correspondants sont à évacuer dans des tables ad-hoc.

[fsmrel]

J’ai omis de présenter un diagramme en relation avec le problème posé par le bonhomme Null. Je propose donc (à compléter pour prendre en compte les quotas mensuels) :

[othmanus]

Bonsoir,
Dans un 1er temps, faisons au plus simple :




Si l’attribut mois (table QuotaMensuel) dépend aussi de l’année, on peut ajouter un attribut Annee participant à la clé de la table.

Afin d’éviter la présence du bonhomme Null, c'est-à-dire si les quotas accordés ne sont pas encore connus, les attributs correspondants sont à évacuer dans des tables ad-hoc.

Bonjour, et merci pour votre réponse.

Puis-je comprendre que je n'ai pas besoin d'un ID_QuotaAnnuel (ainsi qu'un ID_QM) ?

J'ai éliminé la table "Quotas" qui me génait en fait, et j'ai fais exactement la même chose que votre proposition.

Ceci dit, y a-t-il pas de redondance de données si on prends en compte la relation entre ANNEE et MOIS (la table de jointure entre eux) ?
Puisque ANNEE est reliée avec deux tables différentes (BARRAGE et MOIS).

Sinon comment régler ce souci?

[Richard_35]

Bonsoir à tous,

Je me permets de m'immiscer...

Bien entendu, le mois sera forcément sous la forme année/mois. En final, au niveau du MCD, peut-être un truc du style :

T_BARRAGE :
- Code_Barrage_Int (PK)
...

T_ANNEE :
- Code_Barrage_Int (PK)
- Annee (PK) => AAAA
- AEP_Demande
- AEP_Accorde
- IRR_Demande
- IRR_Accorde
...

T_MOIS :
- Code_Barrage_Int (PK)
- Annee (PK) ==> AAAA
- Mois (PK) ==> MM
- AEP_Demande
- AEP_Accorde
- IRR_Demande
- IRR_Accorde
...

Relations :
T_BARRAGE (1,n)---[associé à]---(1,1) T_ANNEE, via Code_Barrage_Int ;
T_ANNEE (1,n)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee.

Vite fait, car il est tard.

[fsmrel]

Bonsoir,

Puis-je comprendre que je n'ai pas besoin d'un ID_QuotaAnnuel (ainsi qu'un ID_QM) ?

Quelle est la valeur ajoutée de cet attribut ID_QuotaAnnuel ? Pour ma part je n’en vois pas, d’où un coup de rasoir d’Ockham.

Ceci dit, y a-t-il pas de redondance de données si on prends en compte la relation entre ANNEE et MOIS (la table de jointure entre eux) ?
Puisque ANNEE est reliée avec deux tables différentes (BARRAGE et MOIS).

Pourquoi voulez-vous faire d’ANNEE et MOIS des tables ? Les ramener au rang d’attributs lambdas suffit largement. On s’en rend compte à l’examen du contenu des tables. Par exemple, pour reprendre celles que je vous ai proposées :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
Barrage {CodeBarrage,  NomBarrage, ...}
         -----------   ----------  ---
                   1   barrage a
                   2   barrage b
                 ...   ...

QuotaAnnuel {CodeBarrage,  Annee,  AEPdemande, IRRdemande, ...}
             -----------   -----   ----------  ----------  ---
                       1    2010         1000        2000
                       1    2011         1200        2500
                       1    2012         1300        2500
                       2    2010         1500        1500
                     ...     ...          ...         ...

[othmanus]

Merci pour vos remarques.

Effectivement, les tables MOIS et ANNEE me gênaient, et qu'on peut facilement s'en passer.

[othmanus]

Bonsoir à tous,

Je me permets de m'immiscer...

Bien entendu, le mois sera forcément sous la forme année/mois. En final, au niveau du MCD, peut-être un truc du style :

T_BARRAGE :
- Code_Barrage_Int (PK)
...

T_ANNEE :
- Code_Barrage_Int (PK)
- Annee (PK) => AAAA
- AEP_Demande
- AEP_Accorde
- IRR_Demande
- IRR_Accorde
...

T_MOIS :
- Code_Barrage_Int (PK)
- Annee (PK) ==> AAAA
- Mois (PK) ==> MM
- AEP_Demande
- AEP_Accorde
- IRR_Demande
- IRR_Accorde
...

Relations :
T_BARRAGE (1,n)---[associé à]---(1,1) T_ANNEE, via Code_Barrage_Int ;
T_ANNEE (1,n)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee.

Vite fait, car il est tard.

Ceci dit, et même si j'ai déjà cliqué sur "Résolu", j'aimerai bien poser une petite question pour mieux clarifier :

J'aimerai remplir mes tables à partir d'un formulaire dans mon application, donc au départ (mis à part la table Barrage), mes tables sont vides.

Mais selon la deuxième association (entre T_ANNEE et T_MOIS), les champs des attributs associés doivent exister dans la table "T_ANNEE" avant d'exister dans la table "T_MOIS" non?. Or, ce n'est pas toujours le cas.
Par exemple, on commence a remplir les quotas mensuels de l'année 2010 (dans la table "T_MOIS") via mon formulaire, alors qu'on a rien saisi dans la table "T_ANNEE".

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
T_ANNEE
Code_Barrage	Annee	AEP_Dem	AEP_Acc	IRR_Dem	IRR_Acc

<TABLE VIDE>

T_MOIS
Code_Barrage	Annee	Mois	AEP_Dem	AEP_Acc	IRR_Dem	IRR_Acc
           1	2010	1	5000	3200	10000	7800
           1	2010	2	5000	3200	10000	7800
           1	2010	3	5000	3200	10000	7800
           2	2010	1	5000	3200	10000	7800

Je ne sais pas si vous voyez se que je veux dire?! mais sinon, dois-je contourner ce problème en programmant mon application?

[fsmrel]

Bonsoir,

T_ANNEE (1,n)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee.

selon la deuxième association (entre T_ANNEE et T_MOIS), les champs des attributs associés doivent exister dans la table "T_ANNEE". Or, ce n'est pas toujours le cas.
Par exemple, on commence a remplir les quotas mensuels de l'année 2010 (dans la table "T_MOIS") via mon formulaire, alors qu'on a rien saisi dans la table "T_ANNEE".

L’association-type entre T_ANNEE et T_MOIS rend dépendantes des données qui ne le sont pas, elle doit être passée au rasoir d’Ockham (même pas mal). Utilisez le modèle que je vous ai proposé :

Ou encore si ce qui est accordé l’est ultérieurement a ce qui a été demandé :

[Richard_35]

Bonjour à tous,

En fait, tu veux que chaque entité "vive leur vie de leur côté" pour, après coup, les lier entre elle.

La solution de Fsmrel fonctionne.

Sinon, il suffit de modifier les relations comme suit :

• T_BARRAGE (0,n)---[associé à]---(1,1) T_ANNEE, via Code_Barrage_Int ;
• T_ANNEE (0,n)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee.

Ainsi, dans le formulaire de saisie de T_MOIS, au lieu de présenter la liste des années existantes dans T_ANNEE, tu peux présenter un joli composant "calendrier" présent dans tous les bons environnements de développement digne de ce nom.

[fsmrel]

Sinon, il suffit de modifier les relations comme suit :

• T_BARRAGE (0,n)---[associé à]---(1,1) T_ANNEE, via Code_Barrage_Int ;
• T_ANNEE (0,n)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee.

Ainsi, dans le formulaire de saisie de T_MOIS, au lieu de présenter la liste des années existantes dans T_ANNEE, tu peux présenter un joli composant "calendrier" présent dans tous les bons environnements de développement digne de ce nom.

Mais pourquoi donc s’acharner à établir une relation contraignante (an unorthogonal one comme dirait Date) entre T_ANNEE et T_MOIS ? Je ne vois pas en quoi le composant « calendrier » exigerait cette relation. Et même si cela rendait service, une vue suffirait pour l'établir de façon virtuelle (je pars sur le diagramme que j’ai présenté) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE VIEW PourJoliCalendrier AS
    SELECT   x.NomBarrage, z.Annee, z.Mois, ...
    FROM     Barrage AS x  JOIN  QuotaAnnuel AS y
              ON  x.CodeBarrage = y.CodeBarrage
                           JOIN  QuotaMensuel AS z
              ON  y.CodeBarrage = z.CodeBarrage
              AND y.Annee = z.Annee ;

[Richard_35]

Bonjour Fsmrel,

Mais pourquoi donc s’acharner à établir une relation contraignante

==> c'est vrai. Mais bon, cela semble plus "propre"...

A terme, selon les besoins de l'application, Othmanus voudra peut-être obliger la présence d'une année pour saisir les données des mois de cette année ((0,n) à passer en (1,n)).

[fsmrel]

Hello Richard,

A terme, selon les besoins de l'application, Othmanus voudra peut-être obliger la présence d'une année pour saisir les données des mois de cette année ((0,n) à passer en (1,n)).

D'après la structure de la table QuotaMensuel que j'ai proposée, pour saisir les données d'un mois, on doit aussi nécessairement renseigner l'année associée.

Une remarque : si vous passez de 0,n à 1,n, alors au niveau des opérations en SQL, il faudra mettre en oeuvre des triggers (ON INSERT, ON UPDATE, ON DELETE) associés aux tables T_ANNEE et T_MOIS. Une usine à gaz, et peut-être mission impossible.


Pour en revenir à la confection d’un calendrier, il faudrait a priori remplacer

T_ANNEE (1,n)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee

par

T_ANNEE (12,12)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee

Hum...

cela semble plus "propre"...

Désolé, mais il ya une grande différence entre "sembler" et "être"...


Sans rancune ?

[Richard_35]

Salut François,

Désolé, mais il ya une grande différence entre "sembler" et "être"...

==> houla !... qu'est-ce-que j'ai pris !... Mais bon, c'est vrai. Bien que, parfois, une certaine dose de relativité soit de mise.

Sans rancune ?

==> non, non, pas de problème.

Une remarque : si vous passez de 0,n à 1,n, alors au niveau des opérations en SQL, il faudra mettre en oeuvre des triggers (ON INSERT, ON UPDATE, ON DELETE) associés aux tables T_ANNEE et T_MOIS. Une usine à gaz, et peut-être mission impossible.

==> attention, je pense que c'est une erreur de vouloir résoudre toutes les problématiques dans le MCD. En final, une application tournera avec les champs de saisie, des listes déroulantes, etc...


Enfin, concernant la partie calendrier, nous avons tout le catalogue possible :

• T_ANNEE (0,12)-----[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee ;
• T_ANNEE (1,12)-----[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee ;
• T_ANNEE (12,12)---[associé à]---(1,1) T_MOIS, via Code_Barrage_Int/Annee.

==> c'est vrai que la dernière est (semble ?...) la plus carrée. Mais ne correspond pas au besoin de Othmanus.