Discussion :

[CinePhil]

J'ajouterai aux remarques de fsmrel que si aujourd'hui il n'y a quye deux produits, demain il peut y en avoir 3, 4, 10...
C'est donc mieux d'externaliser.

[Super2016]

Bonsoir :

Aprés recherche , j'ai trouvé que les deux attributs DATE LIMITE DE TRAITEMENT et DATE DE TRAITEMENT sont +/- Reliés entre eux et donc contraires à la 3NF.

Apparemment , il faut externaliser DATE DE TRAITEMENT .

CDT.

[CinePhil]

Non.
La question à se poser est : "La date limite de traitement est-elle calculable ?"
Par exemple, si vos règles de fonctionnement internes prévoient un traitement sous 8 jours après réception, inutile de stocker la date limite de traitement puisqu'on peut la calculer à partir de la date de réception.
Au contraire, si la date limite de traitement est décidée au cas par cas après la réception selon divers critères de complexité liés à chaque mouvement, il devient pertinent de stocker la date limite. Mais inutile d'externaliser cette date : c'est juste une information.

Je ne suis même pas sûr que vous ayez une contrainte à poser sur la date de traitement par rapport à la date limite de traitement, du genre : "La date de traitement doit être inférieure à la date limite de traitement." Définir une date limite est un objectif. Ce n'est pas certain que cet objectif sera tenu ; la date réelle de traitement sera peut-être supérieure à la date limite.

[fsmrel]

Bonjour Super2016,

Aprés recherche , j'ai trouvé que les deux attributs DATE LIMITE DE TRAITEMENT et DATE DE TRAITEMENT sont +/- Reliés entre eux et donc contraires à la 3NF.

Apparemment , il faut externaliser DATE DE TRAITEMENT .

Comme vous n’avez pas fourni la règle de gestion des données concernant les caractéristiques propres à la date limite de traitement, on peut seulement supposer que si, pour un mouvement donné, la date de traitement est supérieure à la date limite, alors quelqu’un se fera tirer les oreilles.

Maintenant, pour qu’il y ait viol de 3NF, cela veut dire :

D’une part qu’il existe la règle de gestion :

(RGx) Pour une valeur de DateLimiteTraitement il n’y a qu’une et une seule valeur possible pour DateTraitement ;

Et d’autre part que DateLimiteTraitement n’appartient à aucune clé candidate (ce qui est vrai, sinon cette date déterminerait par exemple le montant du mouvement...)

A moins que ce ne soit la règle (vous préciserez laquelle prévaut, si tant est qu’il en est une qui soit effective) :

(RGy) Pour une valeur de DateTraitement il n’y a qu’une et une seule valeur possible pour DateLimiteTraitement.

A supposer que RGx prévale, alors le mouvement 345 ci-dessous est illégal, puisque à la date limite du 30 mai 2018 il existe deux dates de traitement différentes, l’une au 10 mai et l’autre au 25 mai :

MOUVEMENT {idMouvement    Montant    DateLimiteTraitement    DateTraitement}
           123            100        2018_05_30              2018_05_10
           234            250        2018_06_15              2018_05_10
           345            314        2018_05_30              2018_05_25 

Par contre, la situation ci-dessous est légale (bien que la 3NF soit violée, ce qui est mal...) :

MOUVEMENT {idMouvement    Montant    DateLimiteTraitement    DateTraitement}
           123            100        2018_05_30              2018_05_10
           234            250        2018_06_15              2018_05_10
           345            314        2018_05_30              2018_05_10 

___________________

Pour résumer : Si DateLimiteTraitement ne participe à aucune clé et si RGx est vraie (ou RGy, toutes choses égales), alors la 3NF est violée.

Si ni RGx ni RGy ne font partie des règles de gestion des données, alors la 3NF est respectée eu égard aux attributs DateLimiteTraitement et DateTraitement.

Quelle est votre position quant à RGx et RGy ? avez-vous en réserve une autre règle ?

[Super2016]

Bonsoir :

Merci de vos réponses respectives .
Comme vous l'aviez dit, c'est du cas par cas : chaque mouvement a sa propre date limite après calcul .

En fait , Pourquoi on détermine cette date limite: c'est pour ne pas louper / Perdre le Mouvement la réclamation et donc on doit le traiter avant la date limite : Comme le Yaourt qui doit se
manger avant la date limite.

En résumé ci - aprés toutes les règles de gestion :

Règle 1 : Tout mouvement entrant a une et une seule date d'arrivée
Régle 2 : A chaque date, 0 ou n mouvements entrants
Règle 3 : A tout mouvement entrant un et un seul logo de produit lui est associé
Règle 4 : tout mouvement entrant est d'un et un seul type de mouvement
Règle 5 : tout mouvement entrant possède un et un seul code motif
Règle 6 : tout mouvement entrant possède une et une seule date limite de traitement qui est calculé et qui dépend et du logo et du type de mouvement .
Règle 7 : Toute date de traitement doit être inférieure ou égale à la date Limite .


Aprés toutes les modifications, permettez - moi d'ajouter le nouveau MCD :


Est-ce que ce MCD est Juste ? .

CDT.

[fsmrel]

Bonjour Super2016,

Je reviens sur les exemples que j’ai donnés précédemment, et supposons que la 3NF n’y soit pas respectée. Cela veut dire ceci :

(RGx) Indépendamment des sociétés les ayant envoyés, tous les mouvements ayant la même date limite, par exemple "2018-05-30", ont nécessairement la même date de traitement par exemple "2018-05-10".

L’exemple que j’avais donné :

MOUVEMENT {idMouvement    Montant    DateLimiteTraitement    DateTraitement}
           123            100        2018_05_30              2018_05_10
           234            250        2018_06_15              2018_05_20
           345            314        2018_05_30              2018_05_10 

A partir du dernier MCD que vous avez proposé, il faut bien voir qu’au stade du MLD ou du code SQL, la situation deviendra la suivante, où IdTraitement remplace DateTraitement dans l’en-tête de MOUVEMENT :

MOUVEMENT {idMouvement    Montant    DateLimiteTraitement    IdTraitement}
           123            100        2018_05_30              314
           234            250        2018_06_15              425
           345            314        2018_05_30              314 

TRAITEMENT {idTraitement    DateTraitement}
            314             2018_05_10
            425             2018_05_20

C'est-à-dire que les mouvements 123 et 345 ayant la même date limite de traitement 2018_05_30 devront avoir le même IdTraitement, 314 dans l’exemple, pour qu’on aboutisse à la même date de traitement 2018_05_10.

Certes, vous avez externalisé l’attribut DateTraitement, mais son remplacement par IdTraitement fait qu’au lieu d’avoir la dépendance fonctionnelle DateLimiteTraitement → DateTraitement, vous aurez la dépendance fonctionnelle DateLimiteTraitement → IdTraitement, c'est-à-dire que la troisième forme normale ne sera toujours pas respectée !

Ainsi, la mise en oeuvre de l’entité-type TRAITEMENT ne résout rien et ne fait en réalité qu’ajouter des contraintes inutiles et pénibles au stade SQL.

Qui plus est, je doute fort que la règle RGx ci-dessus soit pertinente, autrement dit que la troisième forme normale soit violée.

Oui ou non, la règle RGx est-elle vraie ?

[Super2016]

Bonsoir Monsieur fsmrel :

Je tiens à vous remercier de votre Réponse .

Non , (RGx) Indépendamment des sociétés les ayant envoyés, tous les mouvements ayant la même date limite, par exemple "2018-05-30", ont nécessairement la même date de traitement par exemple "2018-05-10" N'EST PAS VRAIE / N'EST PAS VALIDE .

Les 2 mouvements avec une date limite le 30.05.2018 , l'un est traité le 10.05.2018 et l'autre le 12.05.2018.

La seule contrainte est que 10.05.2018 et 12.05.2018 < 30.05.2018 .

DATE DE TRAITEMENT dépend de DATE LIMITE DE TRAITEMENT vue qu'elle doit être Antérieure , c'est pour cela que j'ai externalisé DATE DE TRAITEMENT .

A Chaque ID_MOUVEMENT ------------- > > > ID TRAITEMENT : Comme une voiture chez un garagiste : A chaque plaque d'Immatriculation Entrante , un ID_RÉPARATION .

Chaque Cas est un Cas : chaque mouvement est traité en fonction de ses propres Caractéristiques.
Je viens de Corriger l'ancien MCD par ce nouveau MCD SUIVANT : Cardinalité Traitement vers MOUVEMENT EST (1,1) :



CDT.

[CinePhil]

NON ! Externaliser la date de traitement ne sert à rien !
J'ai déjà expliqué plus haut pourquoi. A moins que vous ayez d'autres informations relatives aux traitements à enregistrer et que les cardinalités soient différentes de (1,1 - 1,1)... ?

[Super2016]

Bonsoir :

OK on laisse le MCD comme ça :




Avec la contrainte DATE DE TRAITEMENT < DATE LIMITE DE TRAITEMENT , ce que j'espère ne va pas brouiller la 3 FN dans la table MOUVEMENT :




Cdt.

[fsmrel]

Bonsoir,

Non , (RGx) Indépendamment des sociétés les ayant envoyés, tous les mouvements ayant la même date limite, par exemple "2018-05-30", ont nécessairement la même date de traitement par exemple "2018-05-10" N'EST PAS VRAIE / N'EST PAS VALIDE.

Puisque RGx est fausse, si on traduit cela dans le contexte de la théorie relationnelle alors il n’existe pas de dépendance fonctionnelle DateLimiteTraitement → DateTraitement, c'est-à-dire que la 3NF n’est pas violée (la BCNF, la 4NF et la 5NF non plus du reste...) Dans le cadre de la normalisation, il n’y a donc aucune raison d’externaliser DateTraitement.

A Chaque ID_MOUVEMENT ------------- > > > ID TRAITEMENT : Comme une voiture chez un garagiste : A chaque plaque d'Immatriculation Entrante , un ID_RÉPARATION

Plus formellement, soit n le nombre d’attributs de la relvar (variable relationnelle) MOUVEMENT. Le singleton {ID_MOUVEMENT} est clé candidate, c'est-à-dire que pour chaque attribut A_i de MOUVEMENT, il existe la dépendance fonctionnelle :

{ID_MOUVEMENT} → { A_i} 1 ≤ i ≤ n

Et il n’existe aucune autre DF non triviale. Ceci garantit le respect de la 3NF (et mieux, celui de la BCNF).

(N. B. Les accolades sont utilisées parce que {ID_MOUVEMENT} et {A_i} sont des ensembles au sens de la théorie des ensembles, en fait des sous-ensembles de l’en-tête de MOUVEMENT. A noter encore que la dépendance fonctionnelle, {ID_MOUVEMENT} → {ID_MOUVEMENT} est triviale (par réflexivité)).

Toutes choses égales, ce qui vaut pour les mouvements vaut bien entendu pour les réparations de voitures.

Avec la contrainte DATE DE TRAITEMENT < DATE LIMITE DE TRAITEMENT , ce que j'espère ne va pas brouiller la 3 FN dans la table MOUVEMENT

La troisième forme normale n’est absolument pas concernée, pas plus que la BCNF, comme je l’ai déjà évoqué. En revanche, si vous tenez à ce que le SGBD ait connaissance de cette contrainte, rien ne vous empêche de la coder au stade SQL (instruction CREATE | ALTER TABLE) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
 
CREATE TABLE MOUVEMENT
(
        ID_MOUVEMENT ...
        MONTANT ...
        DATE_TRAITEMENT ...
        DATE_LIMITE_TRAITEMENT ...
        ...
        CONSTRAINT MOUVEMENT_CONTRAINTE_01 CHECK (DATE_TRAITEMENT < DATE_LIMITE_TRAITEMENT)
        ... 
) ;

[Super2016]

Bonjour :

J'ai appliqué le script SQL précédent mais la contrainte :

CONSTRAINT MOUVEMENT_CONTRAINTE_01 CHECK (DATE_TRAITEMENT < DATE_LIMITE_TRAITEMENT) n'a pas voulu s'implémenter dans ACCESS et je reçois le
message suivant :


"Erreur de syntaxe dans la clause CONSTRAINT".

CDT.

[Super2016]

La troisième forme normale n’est absolument pas concernée, pas plus que la BCNF, comme je l’ai déjà évoqué. En revanche, si vous tenez à ce que le SGBD ait connaissance de cette contrainte, rien ne vous empêche de la coder au stade SQL (instruction CREATE | ALTER TABLE) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
 
CREATE TABLE MOUVEMENT
(
        ID_MOUVEMENT ...
        MONTANT ...
        DATE_TRAITEMENT ...
        DATE_LIMITE_TRAITEMENT ...
        ...
        CONSTRAINT MOUVEMENT_CONTRAINTE_01 CHECK (DATE_TRAITEMENT < DATE_LIMITE_TRAITEMENT)
        ... 
) ;

Bonjour fsmrel :

J'ai appliqué le script SQL précédent mais la contrainte :

CONSTRAINT MOUVEMENT_CONTRAINTE_01 CHECK (DATE_TRAITEMENT < DATE_LIMITE_TRAITEMENT) n'a pas voulu s'implémenter dans ACCESS et je reçois le
message suivant :


"Erreur de syntaxe dans la clause CONSTRAINT".

CDT.

[fsmrel]

J'ai fait le test sans problème de la contrainte CHECK avec les SGBD relationnels, par exemple SQL Server, mais manifestement le père d'ACCESS a oublié de la prendre en compte, c'est un scandaaaale ! Vous devrez en passer par un trigger (mais bonjour l'angoisse avec ACCESS…) ou du code applicatif…

A moins qu'un spécialiste d'ACCESS ait la solution élégante, voyez le forum ad-hoc...

[Super2016]

J'ai fait le test sans problème de la contrainte CHECK avec les SGBD relationnels, par exemple SQL Server, mais manifestement le père d'ACCESS a oublié de la prendre en compte, c'est un scandaaaale ! Vous devrez en passer par un trigger (mais bonjour l'angoisse avec ACCESS…) ou du code applicatif…

A moins qu'un spécialiste d'ACCESS ait la solution élégante, voyez le forum ad-hoc...

Bonjour fsmrel:

Merci pour votre réponse .

Mais moi j'utilise ACCESS et j'ai eu un vrai blocage .

CDT.

[escartefigue]

Bonjour,

Si vous utilisez ACCESS à titre privé, alors profitez en pour changer de SGBD, il en existe des gratuits autrement plus modernes.
Modernes dans le sens mieux sécurisés, plus performants, plus conformes aux normes SQL et beaucoup plus riches en fonctionnalités.