Discussion :

[fsmrel]

Bonjour Menoto,

Je m'étais demandé si la granularité devait être le cylindre ou le pack

On en revient à la portée de rats. Si donc on pouvait raisonner uniquement en terme de packs, partout où l’on traite du cylindre, on pourrait remonter d’un cran en remplaçant "CYL" par "PAK" (notamment en terme de statut : Partiel, complet, etc.)

Mais, vous rappelez :

Lors du traitement, un ou plusieurs cylindres d'un PACK peuvent-être traités partiellement et les autres complètement.

On est coincés : il faut décomposer le pack en granules plus fins, en fonction de la situation des cylindres, après traitement : pour tel pack P, le traitement d’un sous-ensemble de cylindres est terminé, un autre sous-ensemble se trouve dans l’état partiel, tel autre en dose insuffisante (un sous-ensemble pouvant à la limite correspondre à un singleton {cyl}). Du reste, c’est ce que vous faites quand vous proposez d’utiliser des fourchettes de valeurs :

______Ref A nCylDebut 1 nCylFin 20 Traitement Complet, etc.

Cette dernière façon de procéder n’est pas mauvaise en soi, dans la mesure où elle densifie. Cela dit, si l’on descend au niveau du cylindre, une fourchette peut être reconstituée par agrégation (opérateurs Group by, Min et Max). Le plus sage est de considérer que le granule correspond au cylindre. Sinon à supposer par exemple que votre direction accepte finalement votre proposition du code-barres au niveau du cylindre, si le granule est à un niveau moins fin, la modélisation sera à revoir, avec toutes les conséquences inhérentes.

Exemple d’agrégation : Fournir une liste de regroupements par traitement, référence, statut, premier et dernier numéros affectés à un ensemble de cylindres dans un traitement (cf. mon message du 27/10/2006, 18h03) :

Code :

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

1
2
3
4
5
6
7
8

-- Statut d'un ensemble de cylindres, par traitement, référence, statut

Select r.Trt_Id, c.Ref, r.Statut, Min(r.No_Dans_Trt) as Début, Max(r.No_Dans_Trt) as Fin
From Cylindre c, RCT r
Where c.Cyl_Id = r.Cyl_Id
Group by  r.Trt_Id, c.Ref, r.Statut

Vous aurez noté que l’attribut Cyl_Id ne figure pas dans la requête (pas plus que dans toute autre requête pour laquelle on n’a pas besoin de descendre au niveau du cylindre). Néanmoins, la mise en œuvre de l’entité-type Cylindre (donc de l’identifiant Cyl_Id) reste pour moi quelque chose d’utile et de raisonnable, même si l’utilisateur n’est pas aujourd’hui concerné.

Au besoin, vous pouvez par ailleurs mettre en oeuvre une entité-type PACK, histoire d’y raccrocher les cylindres, si cela apporte un plus.

Avec ce modèle, l'opérateur pourra-t-il sélectionner la quantité de cylindres qu'il souhaite traiter ?

Je l’espère ! Mais nous devons en apporter la preuve : quel est le mode fonctionnement de l'opérateur à ce sujet ?


What do you mean?

Il est sûr que le cylindre étant identifié, l'opérateur devra veiller à ne pas placer sur le convoyeur un cylindre n'appartenant pas à ce TRAITEMENT mais ayant

Vous n’avez par terminé votre phrase, je ne sais donc pas ce que vous attendez...

En tout cas, je crois qu’il est temps que vous décriviez précisément le cycle de vie d’un pack (et d’un cylindre) et la façon selon laquelle votre système va dialoguer avec l’opérateur. Quelles informations doivent lui être impérativement présentées, quelle opération déclencherait le processus d’insertion d’une ligne dans la table des cylindres, à quel moment, etc.

Concernant les statuts :
Inspirez-vous toujours de ce qu’a dit Guillaume d’Ockham : « Ne multipliez pas les entités au-delà du nécessaire ». Si les statuts dans TR_STT_CYL_STK peuvent être inférés de ceux qui figurent dans RCT, alors TR_STT_CYL_STK doit disparaître.

Guillaume d’Ockham et les dates : L’entité-type DATE ne présente guère d’intérêt : Pourquoi ne pas simplement mettre en oeuvre un attribut Date de réception dans TJ_RCP_PDT_CDE ? Sinon vous allez devoir insérer un calendrier perpétuel dans la table DATE dérivée, ne serait-ce que pour des raisons d’intégrité référentielle.

[Menoto]

Bonsoir Mr fsmrel,

il faut décomposer le pack en granules plus fins, en fonction de la situation des cylindres

Oui je pense effectivement que le cylindre serait le niveau de modèlisation approprié compte tenu des contraintes.
Par contre, il traite à peu près 400 000 cylindres par an et il faut sauvegarder sur un minimum de 3 ans, ce qui ferait une table avec plus d' 1 000 000 de lignes. N'est-ce pas gênant pour les performances ? J'utilise SQL Server 2005 Professionnel.

Citation:
Avec ce modèle, l'opérateur pourra-t-il sélectionner la quantité de cylindres qu'il souhaite traiter ?

Je l’espère ! Mais nous devons en apporter la preuve : quel est le mode fonctionnement de l'opérateur à ce sujet ?

Une interface présente à l'opérateur la liste des cylindres en stock non traités.
Ces cylindres sont triés par date limite de traitement. Les plus anciens cylindres en stock devant être traité avant, doivent se situer en haut de la liste.
Tous les cylindres ayant les même paramètres de TRAITEMENT sont regroupés car ces cylindres devront certainement être traités ensemble.

L'opérateur crée un nouveau TRAITEMENT et insère dans ce TRAITEMENT les cylindres présents dans la liste.
Ensuite, les cylindres présents dans ce TRAITEMENT sont traités.

Donc, selon moi,

- soit les cylindres réceptionnés sont ajoutés dans la table T_CYLINDRES_CYL, soit ils sont ajoutés dans la table TJ_RCP_CYL (Table de jonction de réception des cylindres).

- soit les cylindres sont ajoutés dans la table T_CYLINDRES_CYL lorsque l'opérateur ajoute pour la première fois un cylindre dans un TRAITEMENT.

Lors les cylindres sont ajoutés dans le TRAITEMENT, il faut modifier les propriétés de la table TJ_CYL_TRT pour lier les cylindres traités au TRAITEMENT.

Moi je suis assez partagé. Je pencherais pour la première solution. J'ai le sentiment qu'elle est plus cohérente.


Par contre, j'ai oublié un point important qui m'est revenu à l'esprit tout à l'heure: la validation des produits.
Je ne sais pas si vous vous souvenez mais lorsque la référence d'un cylindre est traité pour la première fois, il faut passer par une étape dite de validation qui consiste à déterminer les temps de traitement du cylindre.
Supposons que la référence D n'est jamais été traité.
Et 10 cylindres de cette référence sont à traiter.
Il faut au préalable valider 1 des 10 cylindres pour estimer ses temps de traitement dans les solutions 1 et 2.
Pour cela, l'opérateur estime le temps de trempage nécessaire à cette référence et ajoute dans un TRAITEMENT 1 des 10 cylindres.
Ensuite, il détermine les temps mini et maxi de trempage dans les solutions 1 et 2.
J'ai modifié le MLD que j'ai joint. Il s'appelle TraitementCylindresAvValidation.JPG

J'ai d'ailleurs joint le MLD correspondant à ceci.


J'ai aussi joint un autre MLD.
En fait, ce MLD représente le traitement des commandes et la facturation.
Dans ce MLD, il y a une table T_SERVICES_SVC.
Dans cette table T_SERVICES_SVC:
il y a les services suivants:
Traitement -> pour le traitement des cylindres
Validation -> pour la validation de la référence d'un cylindre
Transport Aller -> pour aller chercher chez le client les cylindres
Transport Retour -> pour ramener les cylindres chez les clients
Transport A/R
etc.

Comme vous le voyez chaque commande peut-être associée à plusieurs services.
Je me demande si j'ai bien fait de mettre l'entité T_SERVICES_SVC ici, car parmi les services, il y a le TRAITEMENT et la VALIDATION dont dépendent normalement les tables dont nous parlons jusqu'à maintenant.
Qu'en pensez-vous ?

Je suis désolé de ce long message.
Encore merci parce que je comprends énormément de chose grâce à vous.
Menoto.

[fsmrel]

Bonjour Menoto,

Il traite à peu près 400 000 cylindres par an et il faut sauvegarder sur un minimum de 3 ans, ce qui ferait une table avec plus d' 1 000 000 de lignes. N'est-ce pas gênant pour les performances ? J'utilise SQL Server 2005 Professionnel.

Le problème de la capacité du SGBD à traiter une telle volumétrie ne doit pas à ce stade de la conception être un élément vous empêchant de dormir et vous faire dévier de votre réflexion, chaque chose en son temps. Concentrez-vous d’abord sur la conception, sinon vous risquez de commettre des boulettes.

Dans la série des a priori, vous vous posez déjà la question suivante : Sommes-nous dans la situation du bonhomme qui est en haut du plongeoir, à trente mètres de haut alors que la bassine tout en bas ne fait qu’un mètre de diamètre ?

Certes, la table de cylindres pourra faire plus d’un million de lignes et la table que j’ai appelée RCT encore plus.

Évidemment, vous pouvez poser la question aux techniciens chez Microsoft (plutôt qu'aux commerciaux...) quelles expériences ont-ils de la gestion de volumétries de cet ordre de grandeur. Vous pouvez interroger les spécialistes de developpez.com connaissant bien SQL Server 2005 Professionnel. Ensuite, pour vous conforter et avoir une vue objective, vous serez amené à mettre en œuvre un prototype, mettant en jeu les quelques tables sensibles et, grâce à des brouillons de transactions ou des outils de simulation, estimer la performance de la base de données et proposer une architecture technique.

Je ne me suis personnellement pas frotté à SQL Server, je suis plus habitué à utiliser DB2 for z/OS (c’est-à-dire sur mainframe), contexte dans lequel 1000 ou 2000 utilisateurs peuvent travailler simultanément, sur des tables de plus de cent millions de lignes : évidemment, pour en arriver là, il y a du travail, mais tout se joue en amont, au niveau de la conception et je parle d’expérience. Si la modélisation est escamotée ou mal faite, il n’y a guère d’espoir ou en tout cas il y aura une débauche d’énergie pour un faible rendement : j’en atteste de par les audits que j’ai été amené à faire.

Pour en revenir à SQL Server 2005, je constate avec satisfaction que ce SGBD permet de mettre en œuvre deux techniques fondamentales, déterminantes, existant dans DB2 depuis la V1 (1983-1984) et dont j’ai usé et abusé :

- Les index de type cluster (regroupement physique des clés selon leur séquence logique). Ceci est déterminant pour la performance des traitements batch ou des transactions lourdes.

- Le partitionnement des tables (il faudra que je lise la littérature SQL Server 2005, histoire de vérifier si c’est bien ce que je crois). Cette facilité permet de considérer de façon transparente une table d’un million de lignes comme seulement un fragment. Par exemple, vous conservez 3 ans de traitements de cylindres : vous pouvez raisonner sur le trimestre ou le mois ou que sais-je, et ainsi seule la partie active de votre table sera à considérer, disons le dernier trimestre et vous pourrez organiser une rotation des partitions.

Quand je dis que la conception n’a pas à être influencée par des considérations physiques, je mens un tout petit peu... Clustering et partitionnement ont une incidence (bénéfique) sur l’organisation des clés primaires : celles-ci doivent porter en racine l’élément générique, associé au clustering : la date, l’identifiant de la commande, l’identifiant du traitement, que sais-je, de telle sorte que l’élément générique se propage tout au long de la chaîne. C’est-à-dire que vous aurez à utiliser l’identification relative au niveau Merise. Votre analyse sera déterminante à ce sujet. Pour mémoire, vous n’utilisez pas actuellement ce type d’identification : je vous engage vivement à vous y mettre.

A titre d’exemple :

Commande -|-----|<=- Ligne Commande,

Plutôt que

Commande -|-----|<-- Ligne Commande

Une interface présente à l'opérateur la liste des cylindres en stock non traités.
Ces cylindres sont triés par date limite de traitement. Les plus anciens cylindres en stock devant être traité avant, doivent se situer en haut de la liste.
Tous les cylindres ayant les mêmes paramètres de TRAITEMENT sont regroupés car ces cylindres devront certainement être traités ensemble.

Parfait. Deux hypothèses :

H1. Lors de la présentation de l’interface à l’utilisateur, les cylindres ne figurent encore dans la table des cylindres (T_CYLINDRES_CYL je suppose) et vous disposez de tous les éléments pour réagir à l'action de l'opérateur.

H2. Vous avez déjà fait figurer tous les cylindres dans cette table, quelle que soit leur situation, auquel cas on peut directement exploiter la table et en présentant à l’opérateur les seuls cylindres qui le concernent.

L'opérateur crée un nouveau TRAITEMENT et insère dans ce TRAITEMENT les cylindres présents dans la liste.
Ensuite, les cylindres présents dans ce TRAITEMENT sont traités.

Tout baigne, dans tous les sens du terme. Si on est dans le cas de l’hypothèse H1, la table des cylindres est mise à jour (Inserts) en fonction de l’action de l’opérateur et la table RCT (TJ_RCP_CYL je suppose) reçoit elle aussi une première rafale d’Inserts.
Si on est dans la configuration H2, la table des cylindres est modifiée si elle a lieu de l’être (Updates) et la table RCT subit une rafale d’Inserts, comme dans la configuration H1.

- soit les cylindres réceptionnés sont ajoutés dans la table T_CYLINDRES_CYL, soit ils sont ajoutés dans la table TJ_RCP_CYL (Table de jonction de réception des cylindres).

Je ne vous suis pas, car je ne vois pas TJ_RCP_CYL dans le modèle en pièce jointe... (un JPG a sauté ?)

- soit les cylindres sont ajoutés dans la table T_CYLINDRES_CYL lorsque l'opérateur ajoute pour la première fois un cylindre dans un TRAITEMENT.
Lors les cylindres sont ajoutés dans le TRAITEMENT, il faut modifier les propriétés de la table TJ_CYL_TRT pour lier les cylindres traités au TRAITEMENT.

Ceci correspond à l’hypothèse H2.

Lors les cylindres sont ajoutés dans le TRAITEMENT, il faut modifier les propriétés de la table TJ_CYL_TRT pour lier les cylindres traités au TRAITEMENT.

Vous aurez noté que les Inserts dans la table RCT sont la conséquence, à mon sens, de l’action de l’opérateur, puisque c’est lui qui tricote cylindres et traitements. Je ne vois pas de modification de propriétés (expression ambiguë au passage).

Moi je suis assez partagé. Je pencherais pour la première solution. J'ai le sentiment qu'elle est plus cohérente.

Je suppose que votre première solution correspond à l’hypothèse H1 et donc votre seconde solution à H2. Si l’une et l’autre se valent, il faut retenir la plus simple et la plus performante.

Supposons que la référence D n'est jamais été traitée. Et 10 cylindres de cette référence sont à traiter.

Si les temps mini et maxi de trempage dans les solutions 1 et 2 sont les mêmes pour les 10 cylindres, la cardinalité de la relation Valider entre T_CYLINDRES_CYL et TJ_CYL_VLD n’est pas 0,n mais 0,1. En plus, la relation est identifiante, TJ_CYL_VLD n’étant qu’une propriété de T_CYLINDRES_CYL qui a été (à juste titre) externalisée.

Si par ailleurs un traitement donné (T_ORDRETRAITEMENT_OTR ?) ne concerne qu’une seule référence (D dans votre exemple) et réciproquement, les temps de trempage devraient être rapatriés dans cette entité-type.

A suivre...

[Menoto]

Bonsoir Mr fsmrel,

oui effectivement j'en écris un peu des tonnes.

C’est-à-dire que vous aurez à utiliser l’identification relative au niveau Merise. Votre analyse sera déterminante à ce sujet. Pour mémoire, vous n’utilisez pas actuellement ce type d’identification : je vous engage vivement à vous y mettre.

Si je comprends bien, vous me conseillez de laisser tomber les identifiants clé primaire comme LIG_ID pour les tables tels que ligne commande qui ne sont que des entités faibles à côté des entités comme commande qui sont des entités principal. Et comme clé primaire de cette entité LigneCommande, vous me conseillez d'utiliser une clé composé de la clé étrangère CDE_ID et PDT_ID ? C'est cela ?


Concernant H1 et H2:

H1. Lors de la présentation de l’interface à l’utilisateur, les cylindres ne figurent encore dans la table des cylindres (T_CYLINDRES_CYL je suppose) et vous disposez de tous les éléments pour réagir à l'action de l'opérateur.

Dans ce cas, effectivement les cylindres réceptionnés sont stockés dans la table TJ_RCP_PDT_CDE. Cette table a une utilité car les cylindres d'une même commande peuvent être réceptionné en plusieurs fois.
Je pense alors développer une vue qui me permette d'extraire les cylindres à traiter.

H2. Vous avez déjà fait figurer tous les cylindres dans cette table, quelle que soit leur situation, auquel cas on peut directement exploiter la table et en présentant à l’opérateur les seuls cylindres qui le concernent.

Oui pour ce cas de figure, tous les cylindres réceptionnés sont stockés dans la table T_CYLINDRES_CYL dans ce cas, la table TJ_RCP_PDT_DATE serait supprimée et une propriété Date de Réception serait ajoutée à la table T_CYLINDRES_CYL.

Si les temps mini et maxi de trempage dans les solutions 1 et 2 sont les mêmes pour les 10 cylindres, la cardinalité de la relation Valider entre T_CYLINDRES_CYL et TJ_CYL_VLD n’est pas 0,n mais 0,1. En plus, la relation est identifiante, TJ_CYL_VLD n’étant qu’une propriété de T_CYLINDRES_CYL qui a été (à juste titre) externalisée.

En fait pour moi, les règles de gestion sont les suivantes:
Une validation correspond à un seul cylindre.
Chaque cylindre peut être validée dans une seul validation.
Donc effectivement, je me suis trompée et la relation entre T_CYLINDRES_CYL et TJ_CYL_VLD est 0,1.
Donc pour TJ_CYL_VLD -> identification relative, n'est-ce pas ?

Si par ailleurs un traitement donné (T_ORDRETRAITEMENT_OTR ?) ne concerne qu’une seule référence (D dans votre exemple) et réciproquement, les temps de trempage devraient être rapatriés dans cette entité-type.

Un traitement donné peut traiter plusieurs références différentes.
Je n'ai pas compris dans quelle entité type les temps de traitement devraient être rapatriés ?

De ce côté les règles de gestion sont :
La validation a lieu dans un TRAITEMENT. J'ai mis la cardinalité 0,1 car lors de la création de la validation, celle-ci n'est pas nécessairement rattachée à un traitement.
Dans un TRAITEMENT, il peut y avoir plusieurs validations.

En fait, une fois la validation effectuée, les temps mini et maxi sont estimée.
Ils apparaissent d'une part dans l'entité TJ_CYL_VLD mais sont ensuite ajoutés dans la table T_PRODUIT_PDT car la validation permet de déterminer les temps de trempage mini et maxi pour la référence d'un cylindre.

Pour la validation j'avais tout d'abord imaginé:
- créer la relation suivante:

T_ORDRETRAITEMENT_OTR <--> TJ_VALIDATION_VLD <--> T_PRODUIT_PDT
où T_ORDRETRAITEMENT_OTR est l'entité des TRAITEMENTS,
TJ_VALIDATION_VLD est l'entité qui mémorise la validation
T_PRODUIT_PDT est l'entité qui mémorise toutes les références des cylindres.

Car, après tout la validation d'une référence produit est réalisée dans un ordre de traitement.
Mais à bien y réfléchir, cette validation doit être facturée au client et en procédant ainsi, la validation n'aurait pas été rattachée à une commande et donc n'aurait pas non plus été rattachée à une facture.

De ce fait, j'ai choisi la solution présentée précédemment.

Qu'en pensez-vous ?

Et que pensez-vous de la gestion des commandes, des services et des factures présentées dans le MLD de mon post précédent.

Vraiment et sincèrement merci.
Suite à tous vos conseils, je vais lire quelques livres pour améliorer mes connaissances scolaires.

A bientôt
Menoto

[fsmrel]

Bonsoir M. Menoto,

fsmrel a écrit :
C’est-à-dire que vous aurez à utiliser l’identification relative au niveau Merise. Votre analyse sera déterminante à ce sujet. Pour mémoire, vous n’utilisez pas actuellement ce type d’identification : je vous engage vivement à vous y mettre.

Menoto pose la question :
Si je comprends bien, vous me conseillez de laisser tomber les identifiants clé primaire comme LIG_ID pour les tables tels que ligne commande qui ne sont que des entités faibles à côté des entités comme commande qui sont des entités principal. Et comme clé primaire de cette entité Ligne Commande, vous me conseillez d'utiliser une clé composée de la clé étrangère CDE_ID et PDT_ID ? C'est cela ?

Bien sûr. Une ligne de commande a-t-elle une existence autonome ? Non. Sémantiquement parlant, elle n’est qu’une propriété de la commande dont on a fait une entité-type au nom de la normalisation.

Au départ, la commande peut avoir l’allure suivante (notez l’imbrication des parenthèses) :

____(1)____Commande (Cde_Id, Cde_Date, LigneCommande (Lig_Id, Art_Id, Quantité, ...), ...)

Où les attributs identifiants (ou clés, selon le niveau) sont soulignés.

Tout naturellement LigneCommande a pour identifiant celui de Commande. Maintenant, il faut distinguer les lignes de commande d’une même commande, d’où l’adjonction d’un attribut pour y parvenir, Lig_Id dans l’exemple (pour sa part, Art_Id symbolise l’article).

Par le jeu de la normalisation, Commande est dédoublée :

____(2)____Commande (Cde_Id, Cde_Date, ...)

____(3)____LigneCommande (Cde_Id, Lig_Id, Art_Id, Quantité, ...)

LigneCommande est identifiée relativement à Commande.

A ce stade, LigneCommande est conceptuellement une entité-type faible (weak) ou encore ce que Codd appelle une entité caractéristique (Characteristic entity) dans RM/T (une entité forte étant une entité noyau (Kernel entity).

Tout va bien, mais interviennent les articles...

Conceptuellement, LigneCommande est une relation (ou association) M,N entre Commande et Article. Dans ces conditions, en Merise, l’identifiant de LigneCommande est « la concaténation » des identifiants des entités-types associées, Commande et Article. Au niveau relationnel, la clé primaire de LigneCommande est donc constituée du couple {Cde_Id, Art_Id}. C’est effectivement une possibilité, auquel cas on a les deux cas de clés primaires :

____(4)____LigneCommande (Cde_Id, Lig_Id, Art_Id, Quantité, ...)

____(5)____LigneCommande (Cde_Id, Lig_Id, Art_Id, Quantité, ...)

La 2e possibilité fait apparaître que Lig_Id (indépendamment de la numérotation des lignes par l’utilisateur) n’a plus d’utilité et peut donc disparaître :

____(6)____LigneCommande (Cde_Id, Art_Id, Quantité, ...)

Au sens de Codd, LigneCommande n’est plus une entité caractéristique, mais une entité associative (Associative entity).

Que faire ? Au fond, c’est à vous d’apprécier, vous êtes absolument libre de retenir la représentation qui vous convient. Basez-vous par exemple sur la propagation qui convient des attributs. En tout cas jusqu’ici, vous avez fait de LigneCommande une entité forte...

Un exemple pour vous faire réfléchir :

Un client passe des commandes.
Une commande est composée de lignes de commande.
Une ligne de commande est composée d’engagements sur ligne.
Un engagement sur ligne de commande est composé de parties (de commande) livrables.

Au niveau opératoire, supposons que pour une partie de commande livrable (PCL) vous ayez besoin de connaître le nom du client.

Selon le système que vous utilisez (pas d’identification relative), vous aurez besoin de mettre en œuvre une quadruple jointure ente les tables Client, Commande, LigneCommande, Engagement, PCL.

Par le jeu de la propagation de l’identifiant du client, une jointure simple suffit...

Et je ne parle pas de l’effet cluster offert par SQL Server, vous permettant de gagner un temps précieux en entrées/sorties...

fsmrel a écrit :
H2. Vous avez déjà fait figurer tous les cylindres dans cette table, quelle que soit leur situation, auquel cas on peut directement exploiter la table et en présentant à l’opérateur les seuls cylindres qui le concernent.

Menoto dixit :
Oui pour ce cas de figure, tous les cylindres réceptionnés sont stockés dans la table T_CYLINDRES_CYL dans ce cas, la table TJ_RCP_PDT_DATE serait supprimée et une propriété Date de Réception serait ajoutée à la table T_CYLINDRES_CYL.

Je n’ai pas la partie du modèle où figure TJ_RCP_PDT_DATE. Le moment venu, il faudra que nous nous assurions que la 3e forme normale est respectée.

menoto dit :
pour TJ_CYL_VLD -> identification relative, n'est-ce pas ?

Yes Sir ! (Jean in "Les tontons flingueurs")

fsmrel a écrit :
Si par ailleurs un traitement donné (T_ORDRETRAITEMENT_OTR ?) ne concerne qu’une seule référence (D dans votre exemple) et réciproquement, les temps de trempage devraient être rapatriés dans cette entité-type.

menoto écrit :
Un traitement donné peut traiter plusieurs références différentes.
Je n'ai pas compris dans quelle entité type les temps de traitement devraient être rapatriés ?
pour TJ_CYL_VLD -> identification relative, n'est-ce pas ?

Je voulais parler de T_ORDRETRAITEMENT_OTR. Mais puisqu’un traitement peut concerner plusieurs références, ma remarque devient sans objet.

Pour la validation j'avais tout d'abord imaginé:
- créer la relation suivante:
T_ORDRETRAITEMENT_OTR <--> TJ_VALIDATION_VLD <--> T_PRODUIT_PDT
où T_ORDRETRAITEMENT_OTR est l'entité des TRAITEMENTS,
TJ_VALIDATION_VLD est l'entité qui mémorise la validation
T_PRODUIT_PDT est l'entité qui mémorise toutes les références des cylindres.
Car, après tout la validation d'une référence produit est réalisée dans un ordre de traitement.
Mais à bien y réfléchir, cette validation doit être facturée au client et en procédant ainsi, la validation n'aurait pas été rattachée à une commande et donc n'aurait pas non plus été rattachée à une facture.
De ce fait, j'ai choisi la solution présentée précédemment.
Qu'en pensez-vous ?

Si je fais référence à votre précédent message (fichiers JPG), Une validation (entité-type TJ_VALIDATION_VLD) détermine un cylindre (TJ_CYL_TRT) qui détermine un détail commande (TJ_CDE_TRT_CYL) qui détermine une commande (T_COMMANDE_CDE) qui détermine une facture (T_FACTURE_FAC), donc une validation détermine une facture. Dans ces conditions, où est le problème ?

Et que pensez-vous de la gestion des commandes, des services et des factures présentées dans le MLD de mon post précédent.

Je pense que j’ai envie de souffler un peu !

En attendant, mettez de l’identification relative en cherchant quel est le meilleur élément racine (générique). A priori, comme dans bien des cas de figure, l’identifiant du client est un choix intéressant. Mais, il faut confronter cela à la conservation sur 3 ans, c’est-à-dire voir à partir de quel niveau il peut y avoir un frottement entre par exemple l’identifiant du client et la date (ou période...), raisonnez en tenant compte du nombre d’opérateurs travaillant simultanément, quels sont les traitements batch etc.

A plus tard

[Menoto]

Je pense que j’ai envie de souffler un peu !

Oui je comprends tout à fait, j'ai d'ailleurs le sentiment d'avoir abusé de votre gentillesse.
Vraiment un grand merci pour votre aide.
A bientôt
Menoto