Discussion :

[Menoto]

Bonjour,

Je dois concevoir le MCD d'un système de traitement d'articles. J'ai réalisé le MCD mais je bloque pour le terminer. Je l'ai joint à ce thread.
Les articles sont des cylindres de différentes formes, constitutions mais quel que soit l'article, le traitement est le même. Il faut tremper le produit dans deux solutions chimiques pour traiter l'article. Les solutions ont la même composition chimique quelque soit l'article. Seul le temps de traitement dans la solution 1 ou la solution 2 varie pour certains produits. Plusieurs articles peuvent avoir le même temps de traitement.
Le client commande le traitement d'article. Ils sont réceptionnés, traités puis réexpédiés au client.
Les articles doivent être référencés chez nous car chaque nouveau produit doit faire l'objet d'un traitement de manière à déterminer les temps de traitements dans les solutions 1 et 2.
J'espère que ces premières explications sont claires.

J'ai fait les entités

Client(IdClient,Nom,Adr,Tel,Fax)
Article(IdArticle,Reference,Designation,TempsTraitement1,TempsTraitement2)

Les articles doivent être référencés.
TempsTraitement1 est le temps de traitement dans la solution 1.
TempsTraitement2 est le temps de traitement dans la solution 2.

Chaque article provient d'un seul et unique client.
Chaque client possède 0 ou plusieurs articles référencés chez nous.
Relation:Provient

Chaque client possède 0 ou plusieurs commandes.
Chaque commande appartient à 1 seul et unique client.

Commande(IdCde,Désignation)
Relation: posséder

Chaque commande concerne un ou plusieurs articles référencés
Chaque article appartient à 0 ou plusieurs commandes.

DétailCommande(IdDetailCde,Qute)
et les relationscorrespond

Chaque article d'une commande peut être réceptionné à des dates différentes.
Relation:réceptionné

Ensuite chaque article réceptionné et appartenant à une commande (les articles en stocks) sera traité dans un ou plusieurs Traitements.

Traitement(Ref,Designation,DateDebut,DateFin);

Les articles en stocks peuvent être traité dans des traitements différents. Relation: Traiter(Tra_Qute)
L'utilisateur devra choisir une quantité de produit à traiter parmi les produits en stocks.

Si le traitement se passe bien, s'il est complet, le produit ne sera traité que dans un seul traitement par contre, il se peut que cet article ne soit traité que partiellement, qu'il n'ait été trempé que dans la cuve 1 mais pas dans la cuve 2. Dans ce cas, il devra être traité dans un autre traitement mais cette fois-ci que dans la cuve 2.
L'article peut aussi être retraité dans un traitement un temps additionnel si le responsable détermine que le temps du premier traitement n'était pas suffisant.
Chaque article traité à un identifiant unique dans le traitement.
Le traitement possède plusieurs identifiants chacun correspondant à un article traité.

Pour savoir si le produit dans le traitement a été traité, je pense utiliser un statut.
Le statut non traité si l'article n'a pas eu le temps d'être traité dans le traitement.
Le statut complet si l'article a été traité comme prévu.
Le statut partiel si l'article n'a été traité que dans une solution1.
Le statut insuffisant si l'article n'a pas été traité suffisemment longtemps.

Mon problème est maintenant pour relier les statuts au traitement et au DetailTraitement.
Je pense que dans le MPD il y aura une table ayant pour clé primaire la référence du traitement, l'identifiant et le statut (si je garde le statut).

Mais je me demande si je dois le relier à la relation Traiter et si c'est possible vu que Traiter est une relation.

J'espère que vous aurez pris le temps de lire ce long message.
Merci en tout cas d'avance pour vos conseils.

[fsmrel]

Vous avez des scrupules à établir une relation entre une entité (STATUT_TRT) et une relation (TRAITER). Et pourtant vous l’avez déjà fait par ailleurs ! De fait, sémantiquement parlant, DETAIL COMMANDE n’est jamais qu’une relation entre ARTICLE et COMMANDE, dont vous avez fait une entité. Dans ces conditions, qu’est-ce qui vous retient d’en faire autant pour TRAITER et d’en faire une entité ?

Au risque de choquer, je dirai que DETAIL COMMANDE est à la fois un carré et un rond, c’est donc un « carrond ». En effet, untel perçoit un détail de commande comme une relation et tel autre comme une entité. Je me souviens des soucis qu’avait un concepteur dans une banque. Celui-ci avait modélisé une opération sur titre comme une relation entre un titre, un trader, un broker, une place cotation, etc. Tout allait bien. Hélas ! l’utilisateur qui se piquait de connaître la modélisation a exigé que cette opération fasse l’objet d’une entité. J’ai expliqué au concepteur que le client était roi et qu’il fallait se plier à sa vision des choses. En effet, que l’opération soit représentée sous forme de carré ou de rond, peu importe, car après dérivation on produit des tables et le résultat est le même. Au fait, pourquoi l’utilisateur avait-il exigé que l’opération sur titre fasse l’objet d’une entité ? Tout simplement pour des raisons émotionnelles, car à l’époque, les titres furent dématérialisés, les papiers réduits à l’état de confettis ou de cendres, mais l’utilisateur en manque sentait toujours son carnet à souches dans sa poche, un peu comme le manchot a mal à son bras manquant...

A mon sens, DETAIL COMMANDE peut être considérée comme une entité associative (concept que j’ai irrespectueusement appelé carrond). Pour ma part, il y a longtemps que j’ai abandonné les ronds qui m’ont fait perdre trop de temps. Manifestement, vous utilisez Power AMC : je vous conseille de faire au moins une fois l’expérience consistant à cliquet sur l’onglet Outils, de choisir Options du modèle puis de sélectionner Entité/Relation dans la boite Notation. Vous serez déboussolé pendant 5 minutes mais vous constaterez que vos scrupules deviendront sans objet...

DETAIL_TRAITEMENT trouvera peut être alors sa place dans le puzzle.
_

[Menoto]

Bonjour,

je vous remercie pour votre aide. Vous m'aviez déjà conseillé auparavant de choisir sous PowerAMC l'option d'affichage entite/relation.
Effectivement, j'ai déjà transformé ma relation DETAIL_CDE en entité.
J'avais avant cela étudier les dépendances fonctionnelles et était arrivé à la conclusion qu'il y avait une agrégation entre l'entité TRAITEMENT et la relation DETAIL_CDE.

Le traitement ne peut avoir lieu que sur des articles en stocks.
Pensez-vous que je doive laisser la relation traiter entre TRAITEMENT et DETAIL_CDE ou que je doive utiliser une entite STOCK ce qui donnerait:

DETAIL_CDE <-> STOCK <-> traiter <-> TRAITEMENT

Pour en revenir à DETAIL_TRT, je serai tenté de le relier à la relation Traiter, mais si je réfléchis au MPD, je me dis que la table DETAIL_TRT devrait avoir pour clé primaire {ID_TRT,ID_ART_DANS_TRT}.

Hors si dans mon MCD, je relie DETAIL_TRT à la relation Traiter, en générant mon MPD, je n'aurais pas cette clé primaire et pense que j'ai peut-être un problème de conception... Mais je ne prends peut-être pas le problème comme il faut.

Merci encore.

[fsmrel]

Bonjour,

Le traitement ne peut avoir lieu que sur des articles en stocks

Si je comprends bien, le fait d’être en stock est une caractéristique de l’article, auquel cas, l’entité ARTICLES devrait être dotée d’un attribut à cet effet (de type booléen). Évidemment, une fois satisfaites, les commandes ont un impact sur la situation des stocks, mais cela sort de ce qui nous préoccupe ici. En tout cas, je ne vois pas pour le moment l’intérêt de mettre en oeuvre une entité Stocks.

Pour savoir si l’on peut effectuer un traitement pour un Detail_Commande donné, on peut, par jointure entre Detail_Commande et Articles connaître la situation de l’article déterminé par Detail_Commande.

Pour en revenir à DETAIL_TRT, je serai tenté de le relier à la relation Traiter, mais si je réfléchis au MPD, je me dis que la table DETAIL_TRT devrait avoir pour clé primaire {ID_TRT, ID_ART_DANS_TRT}.

Hors si dans mon MCD, je relie DETAIL_TRT à la relation Traiter, en générant mon MPD, je n'aurais pas cette clé primaire

Il y a beaucoup de "si" dans ce qui suit, mais tout n’est pas encore clair.

Quand vous dites que vous êtes tenté de relier DETAIL_TRT à la relation Traiter, je suppose que le détail d’un traitement s’applique à un détail de commande. Dans cette hypothèse, soit pour un couple {Traitement, Détail commande} on a au plus un détail traitement, soit on en a plusieurs. Si on en a au plus un, le détail traitement est une propriété portée par Traiter. Si on en a plusieurs, alors Detail_Traitement (entité) est à rattacher à Traiter (devenue entité). Un MLD en pièce jointe correspond à cette hypothèse.

Au sujet de l’identification relative.

Je ne reviendrai pas sur les avantages de l’identification relative que l’on tire au niveau des performances des requêtes et de la simplification des requêtes elles-mêmes. Néanmoins, dans ce dernier cas, en faisant référence au MLD en pièce jointe, si l’on veut connaître le statut d’un article (disons 123) pour un traitement donné (disons 314), il suffit de coder :

Select Art_en_Stock
From Article A, Detail_Traitement B
Where B.Art_Id = 123 And B.Trt_Id = 314 And A.Art_Id = B.Art_Id ;

A suivre...

[Menoto]

Bonjour,

et merci pour votre réponse.
Plus j'y réfléchis et plus je m'interroge.
Le traitement concerne des articles appartenant à une commande et réceptionnés donc en stock.
L'article peut-être traité sous un seul Traitement si celui-ci s'est bien passé, ce qui est la majorité des cas.
Sinon il est retraité sous d'autres Traitements.
Ce qui m'embête est de savoir parmi les cylindres sous quel traitement il a été traité.
Le cylindre non traité n'a pas d'identification(enfin ça dépend des clients (Pour certains clients, on a un numéro d'identification unique et ce numéro peut-être lu)).
Le cylindre n'a d'identification que lorsqu'il a été traité. Ce numéro d'identification est un numéro de cylindre dans le traitement. C'est à dire que le premier du traitement a le numéro 1, le deuxième le numéro 2, etc.

Ce qui m'embête est ensuite de modèliser le fait que le cylindre ayant le numéro 1 dans tel traitement a ensuite été traité dans un autre traitement et a tel numéro.
Auriez-vous une idée sur la manière de modèliser ceci ?
A moins que je ne m'y prenne autrement en attribuant le numéro avant le traitement ?

Merci pour vos aides.

[fsmrel]

Bonjour Menoto,

L'affaire se corse (chef-lieu Ajaccio). Voilà que des cylindres déboulent et fichent la patouille, accompagnés de règles de gestion pas évidentes pour ce lui qui ne connait pas votre partie.

Concernant la partie Traitement :
Est-ce que vous pourriez reformuler ces règles plus rigoureusement, complètement, simplement et en nommant les choses toujours de la même façon ?

Merci,

Fsmrel

[Menoto]

Bonsoir,

effectivement, je reconnais qu'il n'est pas toujours évident de me suivre. Désolé.
Je vais tâcher d'être plus clair.

La modèlisation porte sur le traitement de cylindres de différentes formes.
Pour les traiter, il faut les tremper dans deux solutions chimiques (solutions 1 et 2 ) pendant des durées de temps différentes. Les solutions chimiques ont toujours la même composition. Le trempage dans la solution 2 est le plus important. Il faut absolument respecté le temps de trempage dans cette solution.
Les durées de trempage dans les deux solutions varient selon le type de cylindre.

Un client commande le traitement de plusieurs cylindres de type différents.
Les cylindres appartiennent aux clients.
Les cylindres sont réceptionnés, traités puis réexpédiés au client.

Une fois réceptionné, les cylindres d'une commande peuvent être traités sous un TRAITEMENT.

A un TRAITEMENT est associé un temps de trempage A dans la solution 1 et un temps de trempage B dans la solution 2.

Les cylindres d'une commande peuvent-être traité dans plusieurs TRAITEMENTs différents.

Le cylindre non traité n'a pas d'identification(enfin ça dépend des clients (Pour certains clients, on a un numéro d'identification unique et ce numéro peut-être lu)).
Le cylindre n'a d'identification que lorsqu'il a été traité. Ce numéro d'identification est un numéro de cylindre dans le traitement. C'est à dire que le premier du traitement a le numéro 1, le deuxième le numéro 2, etc.

Le traitement d'un cylindre n'a lieu qu'une fois si le cylindre a été correctement traité.
Correctement traité signifie que le cylindre a été trempé pendant le temps A dans la solution 1 et pendant le temps B dans la solution 2.

Le cylindre peut être incorrectement traité.
Plusieurs cas:
- Le cylindre a été trempé que pendant le temps A dans la solution 1 mais n'a pas été trempé dans la solution 2.
Dans ce cas, le TRAITEMENT est annulé et tous les cylindres non traités doivent être remis en stock.
Ainsi dans ce TRAITEMENT, les cylindres complètement traité ont été correctement traités, les cylindres trempés que dans la solution 1 ont été traités partiellement et les cylindres non trempés n'ont pas été traités.
Il faut donc dans un autre TRAITEMENT trempé les cylindre partiellement traité dans la solution 2, et trempé les cylindres non traités dans les deux solutions.

- Le cylindre a été trempé dans la solution 2 mais pendant un temps insuffisant. Dans ce cas, ces cylindres doivent être traités pendant un temps supplémentaire dans un autre TRAITEMENT.

Ce qui m'embête est de savoir parmi les cylindres sous quel traitement il a été traité.
Ce qui m'embête aussi est ensuite de modèliser le fait que le cylindre ayant le numéro 1 dans tel traitement a ensuite été traité dans un autre traitement et a tel numéro.
Auriez-vous une idée sur la manière de modèliser ceci ?
A moins que je ne m'y prenne autrement en attribuant le numéro avant le traitement ?

J'espère avoir été plus clair.
Merci pour vos aides.

[fsmrel]

Bonjour Menoto,

Vous avez effectivement clarifié la situation, mais il reste des zones d'ombre. Je pars néanmoins dans une direction, tant pis si elle n'est pas la bonne, on recommencera.

La partie de la modélisation porte donc sur le traitement de cylindres de différentes formes.
Pour les traiter, il faut les tremper dans deux solutions chimiques (solutions 1 et 2) pendant des durées de temps différentes. Les solutions chimiques ont toujours la même composition...
Les durées de trempage dans les deux solutions varient selon le type de cylindre.

Donc, notre sujet de préoccupation concerne essentiellement des cylindres qui vont en voir de toutes les couleurs, les pauvres.
Vous dites que la durée du trempage est une propriété du type de cylindre (lequel mérite de faire l’objet d’une entité). Quelles sont les autres caractéristiques d’un trempage ? Autrement dit, peut-on intégrer tout ce qui caractérise un trempage (solution 1 d’une part, solution 2 d’autre part) dans l’entité Type de cylindre ?

A un TRAITEMENT est associé un temps de trempage A dans la solution 1 et un temps de trempage B dans la solution 2.

Étant donné que vous aviez écrit préalablement que « Les durées de trempage dans les deux solutions varient selon le type de cylindre » je devrais conclure qu’un traitement détermine un type de cylindre, lequel fournit au traitement les caractéristiques du trempage.
Maintenant, un cylindre est d’un type (de cylindre), il est la propriété d’un client, il a une date de réception. Il a un statut concernant le 1er trempage (non effectué/ effectué,...), un statut concernant le 2e trempage (non effectué/ partiellement effectué/ complètement effectué...)
Un cylindre peut faire l’objet d’une entité, donc on l’identifie disons au moyen d’un attribut nommé par exemple Cyl_Id.

Un TRAITEMENT concerne plusieurs cylindres.
Un cylindre peut faire l’objet de plusieurs traitements.
Appelons RCT la relation entre un cylindre et un traitement.

Ce qui m'embête est de savoir parmi les cylindres sous quel traitement il a été traité.

La relation RCT pourrait être utile pour que vous ne soyez plus embêté.

Ce qui m'embête aussi est ensuite de modéliser le fait que le cylindre ayant le numéro 1 dans tel traitement a ensuite été traité dans un autre traitement et a tel numéro.

Le numéro peut être un attribut de RTC et donc vous pouvez garder la trace des opérations.

Concernant l’annulation d’un traitement, vous pouvez peut-être conserver ce traitement dans la table, en le notant annulé, à des fins statistiques et autres (combien de trempages se sont mal terminés...) C’est vous qui voyez.

A noter que le type de cylindre déterminé par un traitement et par un cylindre faisant l’objet de ce traitement doit être le même. Ceci peut être résolu en identifiant les traitements et les cylindres relativement au type de cylindre.

Je n’ai pas traité complètement votre problème, mais il est préférable que nous nous synchronisions d’abord sur les points principaux.

A suivre...

Ci-joint un bout de MLD

[Menoto]

Bonsoir,

merci pour votre réponse fort interessante.
En fait, on ne peut pas vraiment parler de type de cylindre.
Les cylindres ont une référence.
Plusieurs références peuvent avoir le même temps de trempage.
Il faut effectivement déterminer les temps de trempage d'une référence de cylindres qui n'a encore jamais été traité. Pour cela, l'opérateur estime le temps de trempage nécessaire et ajoute ce produit dans un TRAITEMENT ayant les même temps de trempage.

Les références de cylindres déjà traité doivent être stockés dans une table.
J'avais donc imaginé mettre dans cette table les paramètres de TRAITEMENT puisque selon moi les paramètres de TRAITEMENT de la référence d'un cylindre était une caractéristique du cylindre.

Lors de la création du TRAITEMENT l'opérateur choisit parmi le stock les cylindres à traiter.
Ainsi, il va choisir une référence appartenant à une commande et la quantité qu'il souhaite traiter. Il va ensuite choisir une autre référence de la même commande ou d'une autre commande qui a les même paramètres de traitement que les autres références existants déjà dans le TRAITEMENT.

Ensuite, les temps de trempage du TRAITEMENT seront ceux des cylindres traités. J'avais tout simplement imaginé mettre dans la table TRAITEMENT les temps de trempage du TRAITEMENT.

Supposons que le traitement de cylindre n'a pas été correctement traité (temps insuffisant ou traitement incomplet).

Prenons un exemple.
Le client C a commandé le traitement de :
- 10 cylindres de référence R1
- 8 cylindres de référence R2

Créons un TRAITEMENT T1:
- 6 cylindres R1 auront le numéro 1 à 6
- 5 cylindre R2 auront le numéro 7 à 11

TRAITEMENT T2:
- 4 cylindres R1 auront le numéro 1 à 4
- 3 cylindres R2 auront le numéro 5 à 7

Disons que 4 cylindres R1 parmi les 6 doivent être retraité parce que le traitement a été incomplet, ce sont les cylindres 3, 4, 5 et 6.
Les cylindres concernés doivent être traités dans un autre TRAITEMENT. Cela peut-être le même pour tous les cylindres ou des TRAITEMENT différents.

TRAITEMENT T3:
- 2 cylindres R1 (3 et 4 du traitement T1)

TRAITEMENT T4:
- 2 cylindres R1 (5 et 6 du traitement T1)

Comment modèliser le fait que les cylindres 3, 4, 5 et 6 ont été traités dans d'autres TRAITEMENT ?

Merci d'avance.

[fsmrel]

Bonjour Menoto,

Silence, moteur, les cylindres trempent, 3e !

Pour répondre à la question :

Comment modéliser le fait que les cylindres 3, 4, 5 et 6 ont été traités dans d'autres TRAITEMENT ?

Je suppose que vous parlez des cylindres 3, 4, 5 et 6 de votre exemple, numéros affectés pour le traitement 1.

Si je me base sur l’exemple, je verrais bien quelque chose comme cela :

- Une entité-type nommée Cylindre (ou Article ou autre...) pour décrire les cylindres en stock, ayant pour identifiant Cyl_Id (un banal numéroteur) et pour autre propriété Référence (à moins qu’il y ait déjà une relation entre Cylindre et une entité-type Référence). Je nomme cette propriété Ref_Id.

- Une entité-type Traitement ayant pour identifiant Trt_Id et pour autres propriétés Trait1_Duree et Trait2_Duree (et autres éléments caractéristiques d’un traitement 1 et d’un traitement 2).

- Une relation-type RCT de cardinalités 0,N-0,N entre Cyl et Traitement, porteuse du statut que vous aviez mentionné dans votre 1er message (non traité, complet, partie, insuffisant). Le numéro que vous évoquez dans votre exemple est aussi une propriété de RCT (« 6 cylindres R1 auront les numéros 1 à 6 »). Je le nomme ici No_Dans_Trt.

Ci-joint un MLD.

Quant au code SQL :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
create table CYLINDRE
(
   CYL_ID               INTEGER                not null,
   REF_ID               INTEGER                not null,
   DATE_RECEPTION       DATE                   not null,
   constraint PK1 primary key (CYL_ID)
);
create table TRAITEMENT
(
   TRT_ID               INTEGER                not null,
   DATE_CREATION        DATE                   not null,
   TRAIT1_DUREE         INTEGER                not null,
   TRAIT2_DUREE         INTEGER                not null,
   constraint PPK2 primary key (TRT_ID)
);
create table RCT
(
   CYL_ID               INTEGER                not null,
   TRT_ID               INTEGER                not null,
   NO_DANS_TRT          INTEGER                not null,
   STATUT               CHAR(16)               not null  
        Constraint Type_Unite Check STATUT In ('faire', 'complet', 'partiel', 'insuffisant’),
,
   constraint PPK3 primary key (CYL_ID, TRT_ID),
   constraint FK1 foreign key (CYL_ID) references CYLINDRE (CYL_ID)
   constraint FK2 foreign key (TRT_ID  references TRAITEMENT (TRT_ID)

Exemple (j'ai remplacé les nombres par des symboles)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Cylindre		RCT					Traitement	
Cyl_Id	Ref		Cyl_Id	Trt_Id	No	Statut		Trt_Id	Trait1_Duree	Trait_2_Duree
c1	r1		c1	t1	1	complet		t1		
c2	r1		c2	t1	2	complet		t2		
c3	r1		c3	t1	3	partiel		t3		
c4	r1		c4	t1	4	partiel		t4		
c5	r1		c5	t1	5	insuffisant				
c6	r1		c6	t1	6	partiel				
c7	r1		c11	t1	7	complet				
c8	r1		c12	t1	8	partiel				
c9	r1		c13	t1	9	partiel				
c10	r1		c14	t1	10	partiel				
c11	r2		c15	t1	11	faire				
c12	r2		c3	t2	1	partiel				
c13	r2		c4	t2	2	insuffisant				
c14	r2		c5	t2	3	insuffisant				
c15	r2		c6	t2	4	insuffisant				
c16	r2		c12	t2	5	complet				
c17	r2		c13	t2	6	complet				
c18	r2		c14	t2	7	complet				
			c3	t3	1	complet				
			c4	t3	2	complet				
			c5	t4	1	complet				
			c6	t4	2	complet

Pour savoir si les cylindres 3, 4, 5 et 6 ont été traités dans d'autres traitements (sous-entendu dans > 1 traitement) :

Select Cyl_Id, Count(*)
From RCT
Where Cyl_Id in (3,4,5,6)
Group by Cyl_Id
Having Count(*) > 1;

Merci de me dire si nous commençons à converger.

A suivre...

[Menoto]

Bonjour,

le souci que j'ai est que lorsque l'utilisateur crée un nouveau TRAITEMENT, il choisit une quantité de cylindres d'une certaine référence parmi les cylindres en stock.
J'avais donc modèliser ça ainsi.



Mais comment puis-je relier votre relation RCT à ce modèle, à moins que mon modèle ne convienne pas ?

Merci encore pour toutes vos explications.

[fsmrel]

Ben dites donc, Menoto !

Le phénomène « Portée de rats ». Si les propriétés Detail_Cde_Qute_Art et Tra_Qute correspondent à un nombre de cylindres, ces derniers composent un ensemble, à l’image des ratons que l’on ne considère pas isolément dans la mesure où seule la portée est digne de notre attention. Si maintenant un raton revêt un certain intérêt (parce qu’il va servir par exemple de cobaye), alors on l’identifie.

Autrement dit, dans la mesure où au niveau MCD, vous en êtes resté au niveau de la portée (le paquet de cylindres), vous ne pouvez pas suivre le cycle de vie d’un cylindre en particulier. Or, dans votre précédent message, vous écrivez :

Comment modéliser le fait que les cylindres 3, 4, 5 et 6 ont été traités dans d'autres TRAITEMENT ?

Les cylindres 3, 4, 5 et 6 sont individualisés tous comme certains de nos ratons, ce qui sous-entend la mise en œuvre d’une entité-type à cet effet Cylindre, sans doute dépendant de l’entité-type Détail Commande (qui correspond au granule le plus fin de votre MCD, indépendamment de Traiter qui reste au niveau du paquet, du fait de la propriété Tra_Qute), et à laquelle vient se raccrocher RCT.

Quelque chose comme (façon Power AMC) :

Detail_Commande---0,n---(Composer)---(1,1)---Cylindre--(0,n)---(RCT)--0,n---Traitement

A la prochaine !

[Menoto]

Bonsoir,

et bien encore une réponse fort interessante.
Que dites-vous des schémas que j'ai joint ?

Dans le 1er schéma, l'utilisateur peut créer un TRAITEMENT en précisant la quantité de cylindre qu'il souhaite traiter, et un numéro est attribué à chaque cylindre comme on peut le voir dans l'entité DETAILS CYLINDRE TRAITEMENT. Par contre, vous en conviendrez je pense, qu'il n'est pas possible de savoir (si je reprends mon exemple) que les cylindres 3, 4, 5 et 6 traités dans un TRAITEMENT l'ont aussi été dans d'autres TRAITEMENT. N'est-ce pas ?

Et que pensez-vous du deuxième schéma ?

Merci une fois de plus pour vos bons conseils

[fsmrel]

Bonsoir Menoto,

Dans le 1er schéma, l'utilisateur peut créer un TRAITEMENT en précisant la quantité de cylindre qu'il souhaite traiter, et un numéro est attribué à chaque cylindre comme on peut le voir dans l'entité DETAIL CYLINDRE TRAITEMENT. Par contre, vous en conviendrez je pense, qu'il n'est pas possible de savoir (si je reprends mon exemple) que les cylindres 3, 4, 5 et 6 traités dans un TRAITEMENT l'ont aussi été dans d'autres TRAITEMENT. N'est-ce pas ?

Exact, L’entité-type LISTE DES CYLINDRES TRAITES est du type Portée de rats. Maintenant, à quoi correspond l’attribut NCYLINDRE ? Soit il s’agit d’un sous-ensemble de cylindres ayant un même statut, soit, cas plus probable, vous vous en servez pour mettre en évidence chaque raton, mais sans le mettre en relation avec quelque traitement que ce soit. Dans les deux cas, ce n’est pas d’une très grande utilité. Je note par ailleurs que la propriété QUTE_CYL est redondante puisque, en principe, égale au nombre d’occurrences de cylindres de DETAIL CYLINDRE TRAITEMENT : me trompé-je ?
Ce schéma n’est pas idéal.

Concernant le 2e schéma :

Clairement, vous identifiez chaque cylindre-raton grâce à la propriété ID_CYL. Sous réserve de permuter les cardinalités entre TRAITEMENTS et DETAIL CYLINDRE TRAITEMENT, cette dernière entité-type correspond à RCT. Quant à LISTE DES CYLINDRES TRAITES, a-t-elle une valeur ajoutée ? Si oui, il faut le prouver. Attention à la redondance évoquée précédemment (QUTE_CYL)...
N’oubliez jamais le rasoir d’Ockham : « Ne multipliez pas les entités au-delà du nécessaire » (sous-entendu ne confondez pas cathédrale et usine à gaz...)
http://perso.orange.fr/sos.philosophie/ockham.htm

Courage !
_

[Menoto]

Bonjour,

dans les schémas de mon message précédent, il y une notion temporelle qui n'apparaît pas. Dans la table LISTE DES CYLINDRES TRAITES, il y a la liste des cylindres que l'utilisateur choisit pour le traitement.

Lorsque l'utilisateur crée un TRAITEMENT, il choisit parmi les cylindres en stock la quantité de cylindre qu'il faudra traiter. Ces cylindres appartiennent à une commande et sont d'une certaine référence.

Et dans DETAIL CYLINDRES TRAITEMENT, il y a le numéro de cylindre dans chaque TRAITEMENT. Effectivement, je conçois que ça ne va pas trop.

J'ai étudié le MLD que vous m'aviez proposé.
Comment puis-je représenter les cylindres choisit par l'opérateur à la création du TRAITEMENT ?

Je vais y arriver, je le sens, j'y suis presque.
Enfin beaucoup grâce à vous.
Merci

[Menoto]

Je pense avoir écrit plus vite que je n'ai réfléchi.
Enfin faut pas que je dise des conneries cette fois, je suis sensé avoir réfléchi.
En fait avec le MLD que vous me proposez, lors de la création du traitement, les cylindres sont ajoutés à la table RCT et ont tous la propriété Numéro de cylindre à 0. Et lorsque les cylindres sont traités, le numéro de cylindre est modifié. C'est cela ?
Vous voyez la chose ainsi ?

Donc cela implique que sur la chaîne de traitement, je puisse identifier le cylindre qui est traité (par lecture d'un code barre identificatif) de manière à lui attribuer le numéro de cylindre dans le TRAITEMENT, n'est-ce pas ?

Mais d'un autre côté, je me dit que ce cylindre a quand même une identification, le numéro de cylindre dans le premier traitement.

En effet, supposons que je ne puisse identifier le cylindre traité autrement que par le numéro attribué dans le premier TRAITEMENT.

Pour rappel, si un cylindre a été traité partiellement dans un TRAITEMENT, il devra être traité dans un autre TRAITEMENT.

Il sera possible de retrouver que ce cylindre est d'une référence REF_A et appartient à une commande CDE_1.
Ne serait-il pas possible d'utiliser le numéro de cylindre dans le premier TRAITEMENT pour pouvoir identifier le cylindre et ainsi savoir dans quels autres TRAITEMENT il a été traité ?
Voyez-vous ce que je veux dire ? J'espère avoir été clair.

Merci pour votre aide.

[fsmrel]

Bonjour à nouveau Menoto,

Vous écrivez

En fait avec le MLD que vous me proposez, lors de la création du traitement, les cylindres sont ajoutés à la table RCT et ont tous la propriété Numéro de cylindre à 0. Et lorsque les cylindres sont traités, le numéro de cylindre est modifié. C'est cela ?

C’est une possibilité, bien que ne n’aime trop évoquer le « comment » au niveau de la modélisation. Je me suis basé uniquement sur votre exemple ci-dessous, selon lequel vous numérotez les cylindres pour la durée d’un traitement : le fait que cette numérotation soit effective avant ou après traitement est orthogonal à la modélisation des données : mais après tout, comme dit Laspalès à Chevallier : c’est vous qui voyez...

Votre message du 25/10/2006, 21h43 :

Prenons un exemple.
Le client C a commandé le traitement de :
- 10 cylindres de référence R1
- 8 cylindres de référence R2
Créons un TRAITEMENT T1:
- 6 cylindres R1 auront le numéro 1 à 6
- 5 cylindres R2 auront le numéro 7 à 11

Poursuivons. Utiliser un code barre comme identifiant semble poser un problème car, si j’ai bien compris celui-ci n’est pas toujours présent. Vous pouvez identifier chaque cylindre par le numéro qui lui a été affecté lors du premier traitement, mais je reste sur ma position, selon laquelle cette numérotation des cylindres est tributaire des traitements : si cette numérotation servait aussi pour l’identification des cylindres, on risquerait de contrevenir à l’indépendance des données et des traitements. Comme je l’ai déjà écrit (notamment dans mon message du 27/10/2006, 18h03), j’ai une préférence pour l’identification des cylindres (attribut Cyl_Id) en toute indépendance des traitements. En conséquence, l’attribut No_Dans_Trt de RCT sert uniquement à suivre la vie des cylindres dans leurs trempettes successives. Maintenant, si cela vous est plus facile, vous êtes quand même libre d’identifier en fonction du numéro affecté dans le premier traitement d’un cylindre.
Quoi qu’il en soit, arrivé au niveau opérationnel, quand vous voudrez savoir quels cylindres ont été traités plus d’une fois, au cours de quels traitements et avec quel numéro par traitement, sachant qu’au cours du 1er traitement ('t1'), ont été donnés les numéros 3, 4, 5, 6, 8 aux cylindres qui vous intéressent, vous coderez :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Select x.Cyl_Id, x.Trt_Id, x.No_Dans_Trt
from   RCT x, 
        (Select Cyl_Id
         From RCT a
         Where Exists (
                       Select * from RCT b 
                       Where a.Cyl_Id = b.Cyl_Id 
                         And No_Dans_Trt in (3,4,5,6,8)  
                         And Trt_Id = 't1'
                      )
         Group by Cyl_Id
         Having Count(*) > 1) As y
Where x.Cyl_Id = y.Cyl_Id
;

et par référence au contenu de la table RCT (cf. le même message), en supposant que vous identiffiez les cylindres pour eux-mêmes, vous obtiendrez, (aux fautes de frrappe près) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Trt_Id    Cyl_Id,    No_Dans_Trt
  t1        c3           3
  t1        c4           4
  t1        c5           5
  t1        c6           6
  t1        c12          8
  t2        c3           1
  t2        c4           2
  t2        c5           3
  t2        c6           4
  t2        c12          5
  t3        c3           1
  t3        c4           2
  t4        c5           1
  t4        c6           2

Si vous identifiez les cylindres en fonction du numéro attribué le premier traitement, vous obtiendrez avec la même requête :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Trt_Id    Cyl_Id,    No_Dans_Trt
  t1        3           3
  t1        4           4
  t1        5           5
  t1        6           6
  t1        8           8
  t2        3           1
  t2        4           2
  t2        5           3
  t2        6           4
  t2        8           5
  t3        3           1
  t3        4           2
  t4        5           1
  t4        6           2

Je reste à votre disposition pour tous compléments d’informations que je serai en mesure de vous fournir, en espérant qu’on approche au plus près de la solution à votre problème.

Fsmrel

[Menoto]

On s'en approche, on s'en approche. J'espère ne pas être trop lourd avec toutes mes questions.

C’est une possibilité, bien que ne n’aime trop évoquer le « comment » au niveau de la modélisation.
Je me suis basé uniquement sur votre exemple ci-dessous, selon lequel vous numérotez les cylindres pour la durée d’un traitement : le fait que cette numérotation soit effective avant ou après traitement est orthogonal à la modélisation des données

Je comprends bien mais il faut malgrès tout pour un traitement mémoriser les cylindres choisis par l'utilisateur avant que ceux-ci soit traités, non ?
Vous allez penser que j'ai du mal à comprendre, mais comment verriez-vous la chose ? Parce que ce point me tracasse encore un peu.

Comme je l’ai déjà écrit (notamment dans mon message du 27/10/2006, 18h03), j’ai une préférence pour l’identification des cylindres (attribut Cyl_Id) en toute indépendance des traitements.

Toujours d'accord avec ceci mais phyisiquement, il faut pouvoir déterminer que tel cylindre a tel numéro, non ? C'est pour cela que j'avais pensé au code-barre.

Maintenant, si cela vous est plus facile, vous êtes quand même libre d’identifier en fonction du numéro affecté dans le premier traitement d’un cylindre.

En fait, non pas tellement. J'essaie juste de modèliser de manière optimale, intelligente et efficace ce traitement d'articles.

Merci encore pour votre aide précieuse.

[fsmrel]

Ave Menoto,

Vous évoquez le code barre du cylindre : Manifestement, il établit un pont entre le tangible et l’abstrait. Si tel est le cas il doit faire l’objet d’une propriété dans l’entité-type Cylindre. On a donc les entités-types Cylindre, RCT, et Traitement donnant lieu aux tables suivantes :

Cylindre (Cyl_Id, Code_Barre, Date_Reception, ...) ;
RCT (CYL_ID, Trt_Id, No_Dans_Trt, Statut) ;
Traitement (Trt_Id, Date_Traitement, Trait1_Duree, Trait2_Duree, ...) ;

Les clés primaires sont en italiques et soulignées. Code_Barre est seulement en italiques car clé candidate non retenue pour être clé primaire (on dit que c’est une clé de rechange (Alternate key)).

Pour suivre les aventures du cylindre de code barre b3 (cf. votre message du 25/10/2006, 21h43) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Select c.Code_Barre, r.Trt_Id, r.No_Dans_Trt, r.Statut, t.Date_Traitement
From Cylindre c, Rct r, Traitement t
Where c.Code_Barre = 'b3'
  And c.Cyl_Id = r.Cyl_Id
  And r.Trt_Id = t.Trt_Id
;
 =>
Code_Barre   Trt_Id   No_Dans_Trt   Statut        Date_Traitement
    b3         t1         3         partiel             d1 
    b3         t2         1         partiel             d2
    b3         t3         1         complet             d3

Remarque : deux cylindres ne peuvent avoir même code barre, donc ce dernier pourrait être candidat à être identifiant de Cylindre, mais il est préférable de s’abstenir. En effet, qui affecte sa valeur au code barre ? Peut-il être modifié (suite à erreur par exemple). D’une manière générale, il vaut mieux définir soi-même l’identifiant (Cyl_Id en l’occurrence), au moins on est sûr que des événements extérieurs ne viendront pas nous perturber sur ce point précis. Au niveau de l’instruction Create Table Cylindre, l’attribut Code_Barre devra simplement faire l’objet d’une clause UNIQUE pour garantir l'unicité des codes barres.

Je m’explique au sujet de ma réticence. Je me souviens du système préconisé par les concepteurs dans une grande banque pour identifier les entreprises : leur numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Par ailleurs, le Siren était propagé dans toute la base de données par le jeu des liens clé primaire - clé étrangère. J’ai fait observer que l’INSEE envoyait tous les mois les nombreux correctifs modifiant le Siren des entreprises. Aussitôt, l’identifiant de l’entreprise fit l’objet d’une propriété nouvelle et artificielle, Entreprise_Id. Le numéro de Siren devint un simple point d'entrée dans la table, à usage de l'utilisateur.

[Menoto]

Bonsoir Mr fsmrel,

je vous remercie pour toutes vos réponses.
J'ai repris tout ce que vous m'aviez expliqué, ainsi que le MLD que vous m'aviez proposé et dessiné le schéma joint.
Qu'en pensez-vous ?

Pour remarque, dans la table TJ_CDE_TRT_CYL (qui correspond à DETAIL COMMANDE) et dans TJ_RCP_PDT_CDE (qui correspond à la réception des cylindres) il y a l'attribut suffixé par _PAK. Ces attributs sont le nombre de PACK. En fait, les cylindres sont organisés en PACK. Il y a plusieurs cylindres par PACK.
Je m'étais demandé si la granularité devait être le cylindre ou le pack.
Il est vrai que l'opérateur va traiter tous les cylindres du même pack dans le même TRAITEMENT. D'où mon interrogation. J'ai conservé le cylindre car lors du traitement un ou plusieurs cylindres d'un PACK peuvent-être traité partiellement et les autres complètement.


Malgrès tout, pensez-vous qu'une granularité au cylindre soit vraiment nécessaire ?
On pourrais utiliser un intervalle. Par exemple:

OT1
Ref A nCylDebut 1 nCylFin 20 Traitement Complet
Ref A nCylDebut 21 nCylFin 21 Traitement Partiel
Ref B nCylDebut 21 nCylFin 29 Traitement Complet
Ref B nCylDebut 30 nCylFin 32 Traitement Partiel

Voyez-vous ce que je veux dire ? Qu'en pensez-vous ?

C’est une possibilité, bien que ne n’aime trop évoquer le « comment » au niveau de la modélisation.

Voyez-vous une autre possibilité ?
Avec ce modèle, l'opérateur pourra-t-il sélectionner la quantité de cylindres qu'il souhaite traiter ? 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

Pensez-vous que le code barre soit vraiment nécessaire ?
J'ai peur de ne pas avoir à disposition un code barre pour tous les cylindres car celui-ci n'est pas fourni pour les cylindres d'un client.
J'ai donc proposé de poser un code-barre sur les cylindres lors de leur réception, mais apparemment cela n'est pas prévu pour le moment.


Ne trouvez-vous pas que j'ai mis un peu trop de statuts ?

TR_STT_CYL_STK -> STATUTS DES CYLINDRES STOCKES
Je pense que celui-ci est mal placé ou tout du moins qu'il ne sert pas à grand chose. Je pourrais par exemple supprimer ma table TJ_RCP_PDT_CDE et mettre la date de réception du cylindre dans la table CYLINDRES comme vous l'aviez suggéré. Dans ce cas, je ne mets plus de statuts cylindre et je fusionne cette table avec la table ci-dessous. Qu'en dites-vous ?

TR_STT_CYL_TRT -> STATUTS DES CYLINDRES TRAITES
Celui-ci définit le statut du cylindre traité, pour savoir s'il a été traité correctement ou partiellement.

Merci toujours pour votre aide.
A bientôt,
Menoto