Discussion :

[Menoto]

Bonjour,

je possède une entité CYLINDRES auquel je pensais définir un attribut code-barre qui permet d'identifier le cylindre. Sur conseil de fsmrel, je ne voulais pas faire de cet attribut une clé primaire mais malgrès tout l'utiliser comme identifiant permettant de retrouver cet entité.
Après réfléexion, il s'avère que cet attribut sera nul pendant un certain moment et ne sera mis à jour qu'après. Je trouve relativement étrange d'avoir un identifiant nul et je me retourne vers vous pour avoir votre avis.
Est-il possible d'avoir un identifiant nul (ou vide) ? Ou comme moi pensez-vous que cela n'a pas vraiment de sens ?

Merci d'avance pour vos remarques.

[Le Pharaon]

Ou comme moi pensez-vous que cela n'a pas vraiment de sens ?

Evidemment, je ne crois même pas qu'il existe un SGBD qui puisse te le permettre. Toute propriété de ton entité pourrait être utilisée comme critère de recherche, quelle soit identifiant ou non.

[fsmrel]

Bonjour Menoto,


Par définition les termes "identifiant" et "null" sont contradictoires.

Au niveau SQL il est possible de définir une contrainte comme quoi si deux cylindres ont mêmes code-barres, alors il s’agit du même cylindre (contrainte d’unicité) : clause Unique au niveau de l’instruction Create Table.

Maintenant, au niveau index, que se passe-t-il quand deux lignes de la table Cylindre sont à null pour l’attribut Code-barres ? C’est vraisemblablement SGBD dépendant.

Avec DB2 for z/OS, si l’on code

________Create Unique Where not Null Index XCB On Cylindre...

alors la contrainte d’unicité n’est contrôlée que pour les seules valeurs non nulles. Ça tombe bien.

Avec SQL Server, j’ai l’impression que cette possibilité n’est pas offerte et que NULL compte pour une valeur (à vérifier auprès d’un expert de ce SGBD).

Pour les autres SGBD : regarder leur littérature de référence...

Autre scénario :

Créer une entité-type Code_Barres identifiée relativement à Cylindre (cardinalités 1,1/0,1). Personnellement je penche pour cette solution, car je peux alors tout dire sur les codes-barres et évacuer les valeurs nulles.
__

[Menoto]

Donc effectivement, soit je ne définis pas cet attribut comme identifiant, ou alors je me dis que j'ai peut-être un problème de conception.
Faut que je vois ça...

Ah je n'avais vu votre message Mr fsmrel.
Je vais étudier effectivement cette possibilité.

Merci bien.

[Menoto]

Bonjour à tous,

et merci pour vos réponses.

Par définition les termes "identifiant" et "null" sont contradictoires

C'est bien ce qui me semblait. Je trouvais cela assez curieux aussi.

Créer une entité-type Code_Barres identifiée relativement à Cylindre (cardinalités 1,1/0,1). Personnellement je penche pour cette solution, car je peux alors tout dire sur les codes-barres et évacuer les valeurs nulles.

Effectivement, cela semble être une solution intéressante.

Chaque ligne de mon entité CYLINDRES est attaché à une commande et sera défini comme suit:

COMMANDE <-> LIGNE COMMANDE <-> PRODUITS

LIGNE COMMANDE <- constituer -> CYLINDRES

avec CYLINDRES {CYL_ID, Code Barre, Numéro de Cylindre du client, Numéro de Production du client}

A partir du code-barre, il est possible d'identifier le numéro de cylindre et le numéro de production du client.
La table CYLINDRES est remplie lors de la création du TRAITEMENT.

CYLINDRES <- traiter -> TRAITEMENT

Lors de cette création, la table cylindre sera constituée de lignes dont seul le champ identifiant auto-incrémenté sera déterminé. Tous les autres champs auront des valeurs nulles.
Le numéro de cylindre, le numéro de production et le code-barre seront nulles tant qu'un cylindre n'a pas été traité pour la première fois puisque le code-barre n'est lu que pendant le traitement du cylindre.

Lors du traitement, le code-barre est lu. A partir du code barre le numéro de cylindre et le numéro de production du client sont déterminés.

La question que je me pose est quelle ligne de CYLINDRES puis-je mettre à jour ? Puis-je le faire de manière arbitraire ? Cela ne pose-t-il pas de problème selon vous ?
Ne devrais-je pas mettre les attributs numéro de cylindre et le numéro de production du client dans la table
Je ne pense pas car je n'ai que ces deux informations pour identifier le cylindre.
Je joins un MCD à ce message qui je l'espère ne vous aura pas paru trop confus. Il me reste à le modifier de manière à faire apparaître l'entité code-barre comme le suggère fsmrel.
N'hésitez pas à me dire s'il y a des choses que vous ne comprenez pas et si vous trouvez mon raisonnement un peu curieux.

Merci d'avance.
Menoto

[fsmrel]

Menoto a écrit :
Lors de cette création, la table cylindre sera constituée de lignes dont seul le champ identifiant auto-incrémenté sera déterminé. Tous les autres champs auront des valeurs nulles.
Le numéro de cylindre, le numéro de production et le code-barre seront nulles tant qu'un cylindre n'a pas été traité pour la première fois puisque le code-barre n'est lu que pendant le traitement du cylindre.

Je ne me suis pas bien fait comprendre. Le défi est de ne jamais avoir à manipuler de valeurs nulles : vous risquez de faire comme beaucoup, c’est-à-dire de vous embourber dans la vase de ces trop fameuses valeurs nulles. Et plouf ! vous plongez allègrement et serez pris au piège de la logique à trois états <vrai, faux, peut-être> ! Ne comptez pas sur SQL pour vous aidez, mais plutôt pour vous enfoncez, malgré sa bonne volonté : Tout le monde n’est pas Lukasiewicz. N’oubliez pas que vous manipulez et que c’est déjà assez compliqué en logique binaire <vrai, faux>.

Autrement dit, tant que vous n’avez aucune information sur un cylindre, le résumer à un identifiant n’a pas de sens : n’insérez dans la table des cylindres que lorsque vous avez des informations connues (suite au premier trempage par exemple, quand vous créez une ligne dans TJ_CYL_VLD (cf. mon message du 08/11/2006, 03h13, "MCD de traitement d'articles, Besoin de vos avis et de votre aide"). Ça n'est pas cela qui vous empêchera de présenter l'information que vous souhaitez à l'utilisateur :

Ne confondez pas le quoi et le comment (in english: What, not how)...

En passant, n’oubliez pas de mettre à jour votre MCD, notamment en transformant la cardinalité 0,n en 0,1 concernant TJ_CYL_VLD.

Les lecteurs de ce message pourront se demander à quoi correspond notre dialogue, mais il y a tout un historique autour du sujet ("MCD de traitement d'articles, Besoin de vos avis et de votre aide"). Pas de panique.

[Menoto]

Bonjour,

Je ne me suis pas bien fait comprendre

Si, si, je vais exporter dans une table le code-barre et les informations qui vont avec: le numéro de cylindre du client, le numéro de production du client.

tant que vous n’avez aucune information sur un cylindre, le résumer à un identifiant n’a pas de sens : n’insérez dans la table des cylindres que lorsque vous avez des informations connues

C'est bien ce qui me semblait. Je trouvais ça relativement louche.
Mais dans ce cas, je me demande vraiment comment faire. Je pense être dans une impasse. En effet, je ne peux identifier le cylindre que lorsqu'il est introduit sur le convoyeur ( le lecteur code-barre sans contact est à l'entrée du convoyeur). Et pourtant je pense devoir sauvegarder la liste des cylindres que l'utilisateur souhaite traiter, avant le traitement de ces cylindres mais après l'ordre de traitement crée.
Pour reprendre vos termes, mon problème est que je manipule d'abord une portée de rats ( réception d'un certain nombre de cylindres, d'un certain nombre de packs ) et ensuite je manipule chaque rat ( lors du traitement du cylindre). J'ai bien une idée mais je vais encore me retrouver dans les travers de la redondance. Il faut que je m'inspire de Guillaume d’Ockham.

(suite au premier trempage par exemple, quand vous créez une ligne dans TJ_CYL_VLD

La table TJ_CYL_VLD correspond à la validation. La validation concerne la référence d'un cylindre qui n'a jamais été traité, pas un cylindre lui-même.
Supposons qu'un cylindre soit de référence A. Aucun cylindre de cette référence n'a jamais été traité. Dans ce cas, un cylindre de cette référence doit être validé et fera donc l'objet d'une ligne dans TJ_CYL_VLD. Mais ensuite pour le futur, tous les cylindres de cette référence A ne devront plus être validé.

Ne confondez pas le quoi et le comment

C'est peut-être ça mon problème. Il est vrai que j'ai du mal à les dissocier ces deux-là.

Et bien j'ai le sentiment que ce n'est pas gagné. Je crois que j'ai un peu de mal.
Merci pour votre aide.
A bientôt

[fsmrel]

Bonjour Menoto,

Menoto a écrit :
Pour reprendre vos termes, mon problème est que je manipule d'abord une portée de rats (réception d'un certain nombre de cylindres, d'un certain nombre de packs) et ensuite je manipule chaque rat (lors du traitement du cylindre). J'ai bien une idée mais je vais encore me retrouver dans les travers de la redondance. Il faut que je m'inspire de Guillaume d’Ockham.

A un instant donné, les ratons-cylindres sont donc toujours dans la portée : ils ne sont pas encore munis de leurs propriétés naturelles (code-barres, n° de production, etc.) Bref, ils n’existent pas réellement, en conséquence de quoi on ne peut pas les ajouter à la table des cylindres. Or, l’opérateur doit manipuler des informations qui peut-être n’apparaissent pas encore dans votre MCD : qu’elles y apparaissent ou non, quelles sont-elles exactement ? (des brouillon d’écrans à l’usage de l’opérateur seraient les bienvenus).

Est-ce que l’entité-type TJ-RCP-PDT-CDE peut être une structure d’accueil pour ces supposées données manquantes ?

Si ça n’est pas le cas, et sans oublier Ockham, peut-être sera-t-il nécessaire de mettre en œuvre une entité-type du genre Portée-de-rats-cylindres porteuse de ces propriétés.

La suite du feuilleton « Les ratons-cylindres » au prochain numéro...

[Menoto]

Bonsoir fsmrel,

(des brouillon d’écrans à l’usage de l’opérateur seraient les bienvenus).

Je me souviens que vous m'en aviez déjà demandé, mais je n'ai pas encore réalisé cette interface. Je pensais d'abord réaliser la base de données et ensuite faire l'interface utilisateur.

La table TJ-RCP-PDT-CDE représente le nombre de cylindres et de packs réceptionnés pour une commande donnée et à une date donnée.

Sur chaque Packs, il y a un code-barre. A partir de la lecture de ce code-barre, il est possible d'identifier les informations suivantes:
- référence produit du client
- nombre de cylindres sur le pack
- l'OF du client
Lors de la réception de packs, l'utilisateur scan le code-barre de chaque pack.

Par contre, dans le cas où les cylindres ne sont pas sur des packs, ils sont réceptionnés à l'unité. Sur chaque cylindre, il y a un code-barre qui permet d'identifier:
- la référence du produit du client.
- l'OF du client
Lors de la réception, l'utilisateur scan le code-barre d'un cylindre et saisit la
quantité de tous les cylindres de même référence.

A la fin d'une réception, il est possible de savoir la quantité de cylindres et de packs réceptionné pour une commande.

Pour le traitement, l'utilisateur choisit ensuite parmi le stock la quantité de packs et de cylindres par commande qu'il souhaite traiter.

Je vais me repencher sur tout ça, mais je pense qu'il manque dans ce système des moyens d'identifier les cylindres
Par exemple, un cylindre non traité et présent en stock ne peut-être identifié ce qui signifie, qu'il n'est pas possible de savoir à quelle commande il appartient. Ca me dérange pas mal, mais d'un autre côté, je me demande si cela a vraiment une importance car après tout, que ce soit ce cylindre ou un autre, ce qui compte selon moi est de le savoir une fois que le cylindre est traité. Qu'en pensez-vous ?

A bientôt
Menoto

[fsmrel]

Bonjour Menoto,

Avant d’aller plus loin, il ressort que l’entité-type Cylindre (TJ_CYLINDRES_CYL) pourrait faire l’objet d’un sous-typage :

a) Cylindres sur des packs, que l’on doit pouvoir mettre en relation avec TJ_RCP_PDT_CDE.

b) Cylindres à l’unité, que l’on met en relation avec quoi en amont ? (attention, le détail de commande TJ_CDE_TRT_CYL semble caractéristique des packs).

Pourriez-vous modéliser cette partie, assez cruciale pour le reste ?

Merci en passant de raconter la vie d’un pack et de ses cylindres, du plus haut en amont (commande du client ou que sais-je) et de la même façon la vie d’un cylindre réceptionné à l’unité. On a actuellement des éléments épars, ça serait bien que tout cela soit recentré et mis au propre...

Ne vous inquiétez pas si tout cela prend du temps, mais une fois que vous vous serez engagé sur votre MCD, il vous sera difficile de revenir en arrière.

Tout doit être clarifié, courage.

[ypicot]

(à propos des brouillons de l'IHM)

je n'ai pas encore réalisé cette interface. Je pensais d'abord réaliser la base de données et ensuite faire l'interface utilisateur.

Faire un brouillon de l'IHM permet de préciser un peu ce que désire voir l'utilisateur, et dans quel ordre. En principe, l'IHM est à faire après le MCD, mais je trouve qu'il permet de clarifier certains points et de recentrer la réflexion (particulièrement utile quand on s'égare).

En fait, cela permet d'envisager le pb sous un autre angle que celui du seul MCD, et il est toujours bon d'élargir son point de vue.

Yvan

[fsmrel]

Bonsoir,

Ypicot a écrit :
Faire un brouillon de l'IHM permet de préciser un peu ce que désire voir l'utilisateur, et dans quel ordre. En principe, l'IHM est à faire après le MCD, mais je trouve qu'il permet de clarifier certains points et de recentrer la réflexion (particulièrement utile quand on s'égare).

En fait, cela permet d'envisager le pb sous un autre angle que celui du seul MCD, et il est toujours bon d'élargir son point de vue.

Ypicot a tout dit : Menoto, méditez bien ce qu'il a écrit.

[Menoto]

Bonsoir,

alors j'ai médité tout les bons conseils que vous m'avez donné, mais malheureusement, j'ai du mal à m'en sortir. Je garde espoir. J'y arriverai.

Merci en passant de raconter la vie d’un pack et de ses cylindres, du plus haut en amont (commande du client ou que sais-je) et de la même façon la vie d’un cylindre réceptionné à l’unité. On a actuellement des éléments épars, ça serait bien que tout cela soit recentré et mis au propre...

Vie et parcours d'un cylindre et des packs:
Le client commande le traitement d'une certaine quantité de cylindres.
Les cylindres sont d'une certaine référence.

Lors de la réception, les cylindres se trouvent soit sur des packs ou sont en vrac. Sur un pack, il peut y avoir jusqu'à 20 cylindres. Tous les cylindres sur un pack sont de même référence.
Lors de la réception d'un pack, il y a une fiche (posé par le client)
En scannant la fiche, il est possible de récupérer les informations suivantes:
- Référence du cylindre
- Référence de l'Ordre de Fabrication du client
- Numéro de pack dans l'OF
- Quantité de cylindres sur le pack
Je prévois lors de la réception que l'utilisateur scanne la fiche de chaque pack réceptionné de manière à récupérer les informations précédentes.

Dans le cas, où le cylindre n'est pas sur un pack, il est réceptionné à l'unité (en Vrac). Sur le cylindre, il y a une étiquette qui peut être scanner.
En scannant l'étiquette du cylindre, les informations suivantes sont obtenues:
- Référence du cylindre
- Référence de l'Ordre de Fabrication du client
- Numéro de cylindre dans l'OF
Je prévois lors de la réception que l'utilisateur scanne l'étiquette d'un cylindre et la quantité de cylindre ayant les même caractéristiques ( Référence, OF )

Ensuite tous les cylindres et packs sont placés dans l'entrepôt en attendant d'être traité.
Ensuite pour le traitement, l'utilisateur choisit la quantité de cylindres qu'il souhaite traiter.

Lorsque le cylindre est traité, le code-barre du cylindre est lu à l'entrée ce qui permet d'obtenir les informations suivantes:
- Référence du cylindre
- OF du client
- Numéro de cylindre dans l'OF du client

Ensuite un numéro est attribuée au cylindre et sur une étiquette electronique est mémorisé le numéro de cylindre et la référence de l'Ordre de Traitement dans lequel le cylindre est traité.

J'ai joins à ce message un MCD.
On voit bien la commande passé pour le traitement d'une quantité de cylindres.
Ensuite j'imagine la chose suivante:
La table T_CYLINDRES_CYL représente l'ensemble des cylindres.
Les cylindres sont ajoutés dans cette table lors de la réception.
En effet, lors de la réception, je connais pour chaque référence la quantité de cylindre. Ainsi je pense ajouté dans cette table autant de ligne que de cylindres réceptionné.
Parmi les attributs que j'ai mis dans cette table,
- l'OF qui est défini dès la réception du cylindre.
- le numéro de cylindre qui est modifié de manière arbitraire lorsqu'un cylindre est traité pour la première fois (Pour rappel, un cylindre peut-être traité dans plusieurs traitements). De manière arbitraire signifie que je pense choisir le premier cylindre dont le numéro est null et qui correspond à l'OF lu lors du scan du cylindre dans le traitement.
- le numéro de pack du client dans le cas où celui faisait parti d'un pack. Cette information est défini dès la réception du cylindre.

Voilà comment je pense faire. Mais je pense aussi me tromper. Car cette entité cylindre devrait ne pas être rempli dès la réception car il est impossible d'identifier le cylindre tant que celui n'a pas été traité. En effet, tant que le cylindre n'a pas été traité, toutes les occurences de la table T_CYLINDRES_CYL ont plus ou moins les même caractéristiques.

Mais j'ai du mal à passer de la portée de rats au rat.

Comment feriez-vous pour réaliser un tel MCD ?

Ne vous inquiétez pas si tout cela prend du temps, mais une fois que vous vous serez engagé sur votre MCD, il vous sera difficile de revenir en arrière.

Je trouve cela assez passionnant mais commence à avoir des cheveux blancs à force de me casser la tête sur ce MCD.

Merci d'avance pour vos aides.
HELP PLEASE.

PS: J'y arriverai,J'y arriverai,J'y arriverai

[fsmrel]

Bonsoir Menoto,

Dans mon message du 17 novembre, j'avais évoqué le sous-typage des cylindres : en pack d'un côté, à l'unité de l'autre.

En corrélation, dans votre message du 27, vous racontez dans le détail la vie des packs et celle des cylindres non en packs, mais avec des recouvrements.

Par ailleurs, vous dites qu'il n'est pas possible d'identifier un cylindre tant qu'il n'a pas été traité, mais est-il possible de traiter un cylindre quelconque sans l'avoir identifié ? (ça se mord la queue...)

Décomposons donc le problème.

Scénario 1. S'il n'y avait que des cylindres non en packs, le MCD vous conviendrait-il ? Si oui, pourquoi, sinon pourquoi ? (le coup du vrac, simulacre de pack ?)

Scénario 2. De la même façon, s'il n'y avait que des packs de cylindres, le MCD vous conviendrait-il ? Si oui, pourquoi, sinon pourquoi ?

Nous devons identifier les problèmes posés par chaque scénario pris isolément, pour comprendre ce qui vous gêne dans le passage de la portée au raton, avant d'intégrer le tout.

Au préalable, réécrivez votre dernier message en deux versions, la 1ère en supposant qu'il n' ya que des packs, en faisant abstraction du reste, puis une deuxième version en supposant qu'il n' ya que des cylindres à l'unité.

Do'nt worry