Opérations sur des documents

**fullmetalkeke** · 29/07/2013, 14h53

Bonjour à tous,

cela fait bien longtemps que je n'ai pas travaillé avec une base de données, j'aimerais avoir votre avis sur mon MCD. Il n'y a rien de bien compliqué à mon sens, mais j'aimerai avoir quelques avis afin de savoir si je suis dans la bonne logique.

En appliquant les règles pour le passage de MCD vers MLD j'obtiens ceci :

AGENT(Cp, NomAgent, PrénomAgent, Email, Téléphone, NumBureau, Groupe)
OPERATION(NumOperation, DateHeure)
DOCUMENT(NomDocument, FormatOrigine, FormatSortie, PointLivraison, Priorité, Observations, Quantité)
DOCUMENTSOURCE(#NomDocument, #NumOperation)
STATUTDEMANDE(IdStatut)
ETATDEMANDE(#IdStatut, # NumOperation)

Merci d'avance pour vos réponses

**fsmrel** · 30/07/2013, 02h47

Bonsoir fullmetalkeke,

Envoyé par fullmetalkeke

j'aimerai avoir quelques avis afin de savoir si je suis dans la bonne logique.

Sans explications de votre part, en l’absence des règles de gestion des données, on ne peut que rester muet : décrivez le rôle de chacune vos entités-types, ainsi que de chacune de vos associations, sans oublier les valeurs prises par les cardinalités mini et maxi.

Que veut dire Cp ? Qu’est-ce qu’un groupe ? La propriété Groupe peut-elle prendre n’importe quelle valeur ? Mêmes remarques concernant le point de livraison.

N’oubliez pas que les identifiants doivent être non significatifs et invariants : le nom du document ne peut faire l’objet que d’un identifiant alternatif pour l’entité-type DOCUMENT. Voyez ici.

Proposez quelques exemples d’emprunts par des agents (jusqu’aux restitutions), en ne vous limitant pas aux cas lambdas.

Quant à votre MLD, il n’est pas conforme à votre MCD (cas des tables OPERATION et ETATDEMANDE).

**fullmetalkeke** · 30/07/2013, 11h04

Merci pour votre réponse.
Je vais donc essayer d'être un peu plus explicite.

Sans explications de votre part, en l’absence des règles de gestion des données, on ne peut que rester muet : décrivez le rôle de chacune vos entités-types, ainsi que de chacune de vos associations, sans oublier les valeurs prises par les cardinalités mini et maxi.

-Un agent demande d'effectuer une action sur un, ou un ensemble de documents. (Cet agent est bien sûr en mesure de demander plusieurs actions différentes opérations)
-Un agent est identifié grâce à son numéro de compte (Cp), et caractérisé par son nom, prénom, email, téléphone, numéro de bureau, groupe auquel il appartient.
-Chaque opération est unique et est identifiée par un identifiant unique (numOperation)
-Il est également nécessaire de savoir si une opération a été traitée ou non, (IdStatut est donc un booléen 0 pour non traité, 1 pour traité). Une opération ne pourra posséder qu'un seul statut.
-Une opération pourra donc être effectuée sur un seul ou un ensemble de documents, et un document (ou un ensemble de documents) pourront subir une ou plusieurs opérations
-Un document est identifiable grâce à son nom, et possède comme caractéristiques : le format d'origine, le format de sortie, la quantité, le point de livraison, la priorité, les observations.

Que veut dire Cp ? Qu’est-ce qu’un groupe ? La propriété Groupe peut-elle prendre n’importe quelle valeur ? Mêmes remarques concernant le point de livraison.

Le groupe est le département dont dépend l'agent, ses valeurs sont prédéfinies (8 possibilités). Les valeurs que pourra prendre le point de livraison seront également prédéfinies (3 possibilités).

N’oubliez pas que les identifiants doivent être non significatifs et invariants : le nom du document ne peut faire l’objet que d’un identifiant alternatif pour l’entité-type DOCUMENT.

Les noms des documents sur lesquels les opérations sont possibles ne peuvent pas être modifiés. dois-je modifier quelque chose tout de même ?

Quant à votre MLD, il n’est pas conforme à votre MCD (cas des tables OPERATION et ETATDEMANDE).

En ce qui concerne mes erreurs dans le MLD :
OPERATION(NumOperation, DateHeure, #IdStatut)
ETATDEMANDE n'existera pas.
Je m'étais rendu compte que mes cardinalités n'étaient pas bonnes, les règles que j'avai appliqué ne correspondaient plus du coup.

**fsmrel** · 31/07/2013, 00h49

Bonsoir fullmetalkeke,

Envoyé par fullmetalkeke

Un agent demande d'effectuer une action sur un, ou un ensemble de documents. (Cet agent est bien sûr en mesure de demander plusieurs actions différentes opérations)

Qu’est-ce qu’une action ? Donnez des exemples. Qu’est-ce qu’une opération ? Donnez des exemples. Quelles différences entre une action et une opération ?

Envoyé par fullmetalkeke

Un agent est identifié grâce à son numéro de compte (Cp),

C’est un identifiant « naturel », vraisemblablement significatif, donc pouvant évoluer dans le temps. Par exemple, dans ma propre entreprise mon matricule fut « 201 » puis un jour « 01212 ». Vous ne connaissez pas l’avenir, votre matricule peut changer lui aussi et doit donc devenir identifiant alternatif. Par exemple, qui aurait cru que le système d’immatriculation des véhicules en France aurait pu être chamboulé ? Quel impact sur les bases de données qui ont utilisé l’immatriculation pour identifier les véhicules ?

Vous écrivez qu’un agent fait partie d’un groupe : ce dernier doit faire l’objet d’une entité-type. S’il y a des erreurs de saisie, alors quand l’application comportera des requêtes sur cet attribut, bonjour les résultats. Vous dites qu’aujourd’hui il y a 8 groupes, mais demain ? Toujours dans mon entreprise, on a débuté avec un seul groupe et un beau jour il y en eut 150...

Envoyé par fullmetalkeke

Les noms des documents sur lesquels les opérations sont possibles ne peuvent pas être modifiés. Dois-je modifier quelque chose tout de même ?

Oui. N’oubliez pas qu’au niveau opérationnel, disons SQL, la clé primaire de la table DOCUMENT sera recopiée dans la table OPERATION. Au-delà du problème de l’invariance du nom (ce que nous ne maîtrisons pas), il n’est pas mauvais de penser à la performance du système opérationnel, même si ça n’est pas une préoccupation conceptuelle.

Vous me direz que vous ne gérez pas cent millions de documents, mais un jour vous aurez peut-être affaire à des trames téléphoniques et autres et alors vous vous souviendrez probablement de cet échange...

Pour mémoire, si vous aviez cent millions de trames à gérer, avec disons la structure de votre table DOCUMENT, avec le SGBD DB2, celle-ci occuperait environ 16,3 GO (Gigaoctets), ce à quoi on ajoutera 15,9 GO pour l’index primaire sur le nom, mais il faut voir que chaque accès physique à un enregistrement de la table représentera 6 accès au disque, au lieu de 4 si la clé l’index primaire était un INTEGER (au lieu d’une quarantaine d’octets en moyenne) et un accès au disque c’est gourmand. Et comme il faut voir un peu plus loin, le cas de la table DOCUMENT_SOURCE est encore plus préoccupant : en supposant qu’en moyenne on ait 3 occurrences par document, la table occuperait 16,9 GO (40 octets pour NomDocument + 4 octets pour NumOperation) (au lieu de 5 GO en remplaçant les 40 octets par 4 octets). Quant à l’index primaire de cette table, n’en parlons pas, ou plutôt si : 45,8 GO sur 6 niveaux au lieu de 5 GO sur 4 niveaux.

Vous me rétorquerez qu’aujourd’hui le stockage sur disque n’est pas aussi onéreux qu’hier, mais il y a quand même l’encombrement de la mémoire à l’occasion des entrées/sorties, et si en plus vous avez 1000 tables, ça deviendra un problème terrible, pendant que le marchand de disques, de mémoire et de serveurs se frottera les mains...

Autrement dit, il est des principes qu’il vaut mieux ne pas oublier, notamment l’invariance des clés primaires et la parcimonie.

Qu’est-ce qu’un point de livraison ? Quoi qu’il en soit, faites une entité-type.

Association DOCUMENT_SOURCE : Quelle est son utilité ? Quel inconvénient y a-t-il à établir directement une association entre DOCUMENT et OPERATION ?

**fullmetalkeke** · 31/07/2013, 10h09

Bonjour !

Un agent demande d'effectuer une action sur un, ou un ensemble de documents. (Cet agent est bien sûr en mesure de demander plusieurs actions différentes opérations)

Qu’est-ce qu’une action ? Donnez des exemples. Qu’est-ce qu’une opération ? Donnez des exemples. Quelles différences entre une action et une opération ?

je me suis un peu embrouillé sur le coup, désolé. opération et action sont la même chose, je n'utiliserait plus qu'un seul terme désormais.
Une opération peut être une demande de modification, d'impression, ...

C’est un identifiant « naturel », vraisemblablement significatif, donc pouvant évoluer dans le temps. Par exemple, dans ma propre entreprise mon matricule fut « 201 » puis un jour « 01212 ». Vous ne connaissez pas l’avenir, votre matricule peut changer lui aussi et doit donc devenir identifiant alternatif. Par exemple, qui aurait cru que le système d’immatriculation des véhicules en France aurait pu être chamboulé ? Quel impact sur les bases de données qui ont utilisé l’immatriculation pour identifier les véhicules ?

Vous écrivez qu’un agent fait partie d’un groupe : ce dernier doit faire l’objet d’une entité-type. S’il y a des erreurs de saisie, alors quand l’application comportera des requêtes sur cet attribut, bonjour les résultats. Vous dites qu’aujourd’hui il y a 8 groupes, mais demain ? Toujours dans mon entreprise, on a débuté avec un seul groupe et un beau jour il y en eut 150...

Complétement d'accord avec vous, et à force de me le répéter, ça commence à rentrer

Le soucis est que, nos formations nous préparent relativement mal à anticiper autant de changements et évolutions futures.

Oui. N’oubliez pas qu’au niveau opérationnel, disons SQL, la clé primaire de la table DOCUMENT sera recopiée dans la table OPERATION. Au-delà du problème de l’invariance du nom (ce que nous ne maîtrisons pas), il n’est pas mauvais de penser à la performance du système opérationnel, même si ça n’est pas une préoccupation conceptuelle.

Vous me direz que vous ne gérez pas cent millions de documents, mais un jour vous aurez peut-être affaire à des trames téléphoniques et autres et alors vous vous souviendrez probablement de cet échange...

Pour mémoire, si vous aviez cent millions de trames à gérer, avec disons la structure de votre table DOCUMENT, avec le SGBD DB2, celle-ci occuperait environ 16,3 GO (Gigaoctets), ce à quoi on ajoutera 15,9 GO pour l’index primaire sur le nom, mais il faut voir que chaque accès physique à un enregistrement de la table représentera 6 accès au disque, au lieu de 4 si la clé l’index primaire était un INTEGER (au lieu d’une quarantaine d’octets en moyenne) et un accès au disque c’est gourmand. Et comme il faut voir un peu plus loin, le cas de la table DOCUMENT_SOURCE est encore plus préoccupant : en supposant qu’en moyenne on ait 3 occurrences par document, la table occuperait 16,9 GO (40 octets pour NomDocument + 4 octets pour NumOperation) (au lieu de 5 GO en remplaçant les 40 octets par 4 octets). Quant à l’index primaire de cette table, n’en parlons pas, ou plutôt si : 45,8 GO sur 6 niveaux au lieu de 5 GO sur 4 niveaux.

Vous me rétorquerez qu’aujourd’hui le stockage sur disque n’est pas aussi onéreux qu’hier, mais il y a quand même l’encombrement de la mémoire à l’occasion des entrées/sorties, et si en plus vous avez 1000 tables, ça deviendra un problème terrible, pendant que le marchand de disques, de mémoire et de serveurs se frottera les mains...

Autrement dit, il est des principes qu’il vaut mieux ne pas oublier, notamment l’invariance des clés primaires et la parcimonie.

Merci pour tous les explications et exemples qui les illustrent très bien. Je me représente mieux les choses.

Qu’est-ce qu’un point de livraison ? Quoi qu’il en soit, faites une entité-type.

Pour une demande d'impression, par exemple, l'agent se fera livrer l'impression dans son bureau, à l'accueil, ... dans un lieu qu'il aura précédemment choisi.

Association DOCUMENT_SOURCE : Quelle est son utilité ? Quel inconvénient y a-t-il à établir directement une association entre DOCUMENT et OPERATION ?

Encore un soucis dans les cardinalités : entre documentSource et Document, la cardinalité est 0,N (et non 1,N) car un document peut ne pas subir d'opérations ou en subir plusieurs.
Sauf erreur de ma part, en appliquant la règle Une association binaire de type n :m devient une table supplémentaire (table de jonction) dont la clé primaire est composée des deux clés étrangères
on obtient bien DOCUMENTSOURCE(#NomDocument, #NumOperation) ?

**fsmrel** · 31/07/2013, 15h34

Bonjour fullmetalkeke,

Envoyé par fullmetalkeke

Envoyé par fsmrel

Qu’est-ce qu’un point de livraison ?

Pour une demande d'impression, par exemple, l'agent se fera livrer l'impression dans son bureau, à l'accueil, ... dans un lieu qu'il aura précédemment choisi.

Heu... D’après la structure de l’entité-type DOCUMENT, un document fait référence à un seul point de livraison, par exemple l’accueil, donc l’agent n’a pas le choix, vu la structure de la base de données il ne pourra récupérer l’impression qu’à l’accueil...

Envoyé par fullmetalkeke

Une opération peut être une demande de modification, d'impression, ...

Les documents faisant l’objet d’une demande seraient donc des documents informatisés ? (à moins que l’entreprise ne soit une imprimerie...)

Cela a une influence certaine quant à la signification de certains attributs, donc leur pertinence en relation avec l’emplacement où ils figurent dans le diagramme : le point de livraison en est un exemple. Aussi il faudrait que vous expliquiez le rôle précis de chacun des attributs de l’entité-type DOCUMENT : FormatOrigine, FormatSortie, Priorité, Observations, Quantité. Ce rôle est-il vraiment indépendant des opérations et des agents ?

Envoyé par fullmetalkeke

On obtient bien DOCUMENTSOURCE(#NomDocument, #NumOperation) ?

Oui. Ne tenez pas compte de la question que j’ai posée, qui n’est qu’une scorie que j’ai omis d’effacer...

Cela dit, n’oubliez pas de faire évoluer la structure de l’en-tête de l’entité-type DOCUMENT, en la dotant d’en attribut IdDocument (non significatif...) devenant l’identifiant de l’entité-type, tandis que l’attribut NomDocument sera ravalé au rang d’identifiant alternatif, conservant bien sûr sa propriété d’unicité : simplement on le retrouvera pas en tant que clé étrangère au stade du MLD et vous aurez les structure :

DOCUMENTSOURCE(#IdDocument, #NumOperation)

(Où l’on suppose bien sûr que NumOperation est lui aussi un attribut invariant, non significatif, donc sur lequel l’utilisateur n’a aucun pouvoir).

En passant, notez que dans votre MLD, l’en-tête de la table OPERATION est incomplet, il y manque la référence à l’agent.

**fullmetalkeke** · 01/08/2013, 11h03

Bonjour,

Les documents faisant l’objet d’une demande seraient donc des documents informatisés ? (à moins que l’entreprise ne soit une imprimerie...)

Il ne s'agit pas d'une imprimerie, mais du département reprographie de l'entreprise

Cela a une influence certaine quant à la signification de certains attributs, donc leur pertinence en relation avec l’emplacement où ils figurent dans le diagramme : le point de livraison en est un exemple. Aussi il faudrait que vous expliquiez le rôle précis de chacun des attributs de l’entité-type DOCUMENT : FormatOrigine, FormatSortie, Priorité, Observations, Quantité. Ce rôle est-il vraiment indépendant des opérations et des agents ?

Tous les agents qui auront accès au logiciel auront exactement les même droits, les même possibilités. Et quelque soit l'opération, tous ces attributs recevront une valeur.

ela dit, n’oubliez pas de faire évoluer la structure de l’en-tête de l’entité-type DOCUMENT, en la dotant d’en attribut IdDocument (non significatif...) devenant l’identifiant de l’entité-type, tandis que l’attribut NomDocument sera ravalé au rang d’identifiant alternatif, conservant bien sûr sa propriété d’unicité : simplement on le retrouvera pas en tant que clé étrangère au stade du MLD et vous aurez les structure :
DOCUMENTSOURCE(#IdDocument, #NumOperation)
(Où l’on suppose bien sûr que NumOperation est lui aussi un attribut invariant, non significatif, donc sur lequel l’utilisateur n’a aucun pouvoir).

Je commence à intégrer l'importance et la logique des attributs non-significatifs.

En passant, notez que dans votre MLD, l’en-tête de la table OPERATION est incomplet, il y manque la référence à l’agent.

J'ai effectué quelques modifications hier après midi, et celle-ci en fait partie.

Dans tous les cas, je pense que je commence à y voir plus clair et tout ceci grâce à vous.
Je pense que je devrai réussir à m'en sortir sans trop de soucis à présent.

Merci pour tout !

**fsmrel** · 01/08/2013, 17h35

Bonjour fullmetalkeke,

Envoyé par fullmetalkeke

Il ne s'agit pas d'une imprimerie, mais du département reprographie de l'entreprise.

On comprend mieux le contexte, comme quoi il est très important de le préciser.

Envoyé par fsmrel

Envoyé par fullmetalkeke

Envoyé par fsmrel

Qu’est-ce qu’un point de livraison ?

Pour une demande d'impression, par exemple, l'agent se fera livrer l'impression dans son bureau, à l'accueil, ... dans un lieu qu'il aura précédemment choisi.

Heu... D’après la structure de l’entité-type DOCUMENT, un document fait référence à un seul point de livraison, par exemple l’accueil, donc l’agent n’a pas le choix, vu la structure la base de données il ne pourra récupérer l’impression qu’à l’accueil...

Autrement dit, au vu de la structure de l’entité-type DOCUMENT, si pour le document « Fullmetalkeke, sa vie son œuvre », l’attribut PointLivraison a la valeur « Accueil », contrairement à ce vous laisser entendre, l’agent Raoul qui a fait une demande pour ce document n’aura pas la possibilité de se faire livrer l’impression dans son bureau, il devra se rendre à l’accueil. De même, en supposant que dans la même opération Raoul a aussi demandé de se faire livrer dans son bureau le document « Orwell, 1984 » et que l’attribut PointLivraison a en l’occurrence la valeur « salle 101 », il devra aussi se rendre en salle 101 pour récupérer l’impression.

Envoyé par fullmetalkeke

Tous les agents qui auront accès au logiciel auront exactement les mêmes droits, les mêmes possibilités.

Je ne parle pas de cela, mais du rôle de l’entité-type AGENT et de l’entité-type OPERATION dans le diagramme, en relation avec l’exemple qui précède : si comme vous le dites, Raoul a le choix du lieu où récupérer ses documents, je veux attirer votre attention sur le fait que votre modélisation du point de livraison ne le permet pas et doit être modifiée.

Envoyé par fullmetalkeke

Envoyé par fsmrel

Aussi il faudrait que vous expliquiez le rôle précis de chacun des attributs de l’entité-type DOCUMENT : FormatOrigine, FormatSortie, Priorité, Observations, Quantité. Ce rôle est-il vraiment indépendant des opérations et des agents ?

Quelle que soit l'opération, tous ces attributs recevront une valeur.

C‘est la moindre des choses ! Mais je reste sur ma faim. De même que l’attribut PointLivraison ne me paraît pas être au bon endroit, j’aimerais pouvoir donner un avis sur les autres attributs que j’ai énumérés. Par exemple, que représente exactement l’attribut Quantité ? Une quantité de documents certes, mais je ne suis pas plus avancé : quelle est la véritable finalité de cet attribut ? Quel est son rôle ? Pourquoi est-il présent ? Etc.

Merci de décrire en quelques lignes chacun des attributs que j’ai énumérés, pour que nous puissions conclure qu’ils sont ou non à la bonne place.

**fullmetalkeke** · 06/08/2013, 10h43

Bonjour,

désolé pour le temps de réponse, j'ai eu droit à un week-end prolongé

Merci de décrire en quelques lignes chacun des attributs que j’ai énumérés, pour que nous puissions conclure qu’ils sont ou non à la bonne place.

Je vais essayer d'être plus précis.
Voici un une esquisse de l'interface utilisateur : une demande d'un agent. Ici, la demande concerne l'impression de deux fichiers.

-Le champ quantité représente le nombre d'impression que souhaite l'agent pour le document correspondant
-Le champ format d'origine est le format d'origine du support, ce peut être un format papier ou un format informatique
-Le champ format de sortie correspond à l'opération que devra effectuer la reprographie sur le document
-Le champ priorité pourra prendre 3 valeurs : Haute, Normale et Basse,
-Le champ Point de Livraison correspond à l'endroit où le document doit être livré, il pourra prendre 3 valeurs : Bureau, Accueil, Pas de Livraison(l'agent récupère lui-même le document)
-Le champ observation contiendra un message destiné à la personne s'occupant de la reprographie

Ma mission est donc de remplir une base de données qui contiendra toutes ces valeurs, je précise que toutes les données seront des chaînes de caractères, c'est une contrainte que l'on m'a imposé. Un autre développeur sera chargé de récupérer ces données afin de les intégrer dans l'interface dédiée à la reprographie.

Autrement dit, au vu de la structure de l’entité-type DOCUMENT, si pour le document « Fullmetalkeke, sa vie son œuvre », l’attribut PointLivraison a la valeur « Accueil », contrairement à ce vous laisser entendre, l’agent Raoul qui a fait une demande pour ce document n’aura pas la possibilité de se faire livrer l’impression dans son bureau, il devra se rendre à l’accueil. De même, en supposant que dans la même opération Raoul a aussi demandé de se faire livrer dans son bureau le document « Orwell, 1984 » et que l’attribut PointLivraison a en l’occurrence la valeur « salle 101 », il devra aussi se rendre en salle 101 pour récupérer l’impression.

Voici comment je traduit mon MCD entre OPERATION ET DOCUMENT :
Une opération peut être demandée sur un ou plusieurs documents, un document peut subir 0 ou plusieurs opérations. Sachant qu'un document possède un attribut Point de Livraison, je pensai que ma logique était bonne, et que cet attribut se situait au bon endroit.

Peut être n'avais-je pas été assez précis sur mes explications. En tout cas j'espère que maintenant c'est plus facile à comprendre.

Je tiens encore à vous adresser mes remerciements pour le temps que vous me consacrez.

**fsmrel** · 06/08/2013, 19h09

Bonjour fullmetalkeke,

Envoyé par fullmetalkeke

je précise que toutes les données seront des chaînes de caractères

On dira que ceci est vrai au niveau de la couche présentation : si vous exportez des données à destination d’un autre système, dans le fichier ou la table importé(e)/exporté(e) rien n’empêche de vous conformer aux contraintes. En revanche, dans votre base de données, changement de chanson, une donnée numérique ne doit pas être du type chaîne de caractères, une date doit être du type DATE, etc. : ça serait une régression inadmissible eu égard à l’intégrité des données, et vous vous priveriez en plus des opérateurs proposés par SQL pour ces types. Concernant les fichiers (ou tables) échangé(e)s avec les autres applications, grâce à la fonction CAST, rien ne vous empêchera de convertir un entier ou une date en chaîne de caractères et inversement.

Envoyé par fullmetalkeke

Voici un une esquisse de l'interface utilisateur.

Avec l’image que vous avez fournie on y voit clair (nonobstant sa couleur

) en ce qui concerne les sorties.

Avant d’aller plus loin, à propos de la partie Origine (cf. votre image) :

A quoi correspond l’information « Chemin du fichier ? » Certes, on localise un fichier, mais on a l’impression qu’il s’agit d’un de vos fichiers, figurant sur le disque de votre propre ordinateur. Quelque chose m’échappe, je vois mal comment le service de reprographie arrive à savoir à quoi correspond votre demande.... Pourriez-vous raconter le film pour cette partie précise : l’agent Raoul souhaite l’impression du document « Fullmetalkeke, sa vie son œuvre » (un précis de 1500 pages...)

Par ailleurs, la présence d’un choix « Origine » dans l’image signifie que le document « origine », « source » dont Raoul souhaiterait l’impression peut exister en plusieurs formats d’origine, c’est cela ?

**fullmetalkeke** · 07/08/2013, 09h09

Bonjour,

On dira que ceci est vrai au niveau de la couche présentation : si vous exportez des données à destination d’un autre système, dans le fichier ou la table importé(e)/exporté(e) rien n’empêche de vous conformer aux contraintes. En revanche, dans votre base de données, changement de chanson, une donnée numérique ne doit pas être du type chaîne de caractères, une date doit être du type DATE, etc. : ça serait une régression inadmissible eu égard à l’intégrité des données, et vous vous priveriez en plus des opérateurs proposés par SQL pour ces types. Concernant les fichiers (ou tables) échangé(e)s avec les autres applications, grâce à la fonction CAST, rien ne vous empêchera de convertir un entier ou une date en chaîne de caractères et inversement.

Si ça peut vous rassurer, dans la base de données, les attributs quantité, date, ... sont bien des types spécifiques : integer, datetime, ...

Avec l’image que vous avez fournie on y voit clair (nonobstant sa couleur ) en ce qui concerne les sorties.

Comme je l'ai dit, ceci n'est qu'une esquisse (la bonne excuse !

), les couleurs ont été "choisies" afin de bien délimiter les différents éléments de la page HTML.

A quoi correspond l’information « Chemin du fichier ? » Certes, on localise un fichier, mais on a l’impression qu’il s’agit d’un de vos fichiers, figurant sur le disque de votre propre ordinateur. Quelque chose m’échappe, je vois mal comment le service de reprographie arrive à savoir à quoi correspond votre demande.... Pourriez-vous raconter le film pour cette partie précise : l’agent Raoul souhaite l’impression du document « Fullmetalkeke, sa vie son œuvre » (un précis de 1500 pages...)

Les fichiers qui pourront être traités par la reprographie se trouveront uniquement sur un serveur à part, dédié à la reprographie. J'ai effectué les tests en local, afin de vérifier le comportement principal de l'ensemble des choses déjà réalisées. Enfin il n'est pas possible de vouloir imprimer, par exemple, une partie d'un fichier (un fichier sélectionné sera imprimé dans sa totalité).
"Chemin du fichier" est tout simplement l'endroit où se trouve le fichier. C'est une donnée qui doit être stockée dans la base. L'autre développeur en a absolument besoin pour la deuxième interface.

Par ailleurs, la présence d’un choix « Origine » dans l’image signifie que le document « origine », « source » dont Raoul souhaiterait l’impression peut exister en plusieurs formats d’origine, c’est cela ?

Un fichier aura un seul et unique Format d'Origine parmi plusieurs possibles : Calque, Doc, Papier, ... .

**fsmrel** · 08/08/2013, 04h28

Bonsoir fullmetalkeke,

Pour le moment, j’ai compris qu’un document source (par exemple « Dix ans dans une table la vie d’une ligne ») — ou tout du moins sa référence —, figure sous forme de fichier sur un serveur affecté au service Reprographie. Les agents peuvent demander l’impression d’un ou plusieurs exemplaires de ce document source.

Exemple :

L’agent Raoul souhaite qu’on lui imprime quatre exemplaires (un en couleur et en priorité basse, trois en noir et blanc dont un en priorité basse et les deux autres en priorité normale) de l’ouvrage « Dix ans dans une table la vie d’une ligne », le tout à récupérer là-haut. Pour passer commande, Raoul fournit non pas le nom de l’ouvrage, mais le nom du fichier qui lui est associé, hébergé sur un serveur affecté au service Reprographie.

Il effectue sa demande concernant l’exemplaire en couleur à l’aide du magnifique écran (pour daltonien) :

N.B. Raoul ne remplit pas le champ Origine, puisque, je cite :

Un fichier aura un seul et unique Format d'Origine parmi plusieurs possibles : Calque, Doc, Papier, ...

Je suggère par ailleurs que, si ce n’est fait, le point d’entrée (chemin du fichier) fourni par Raoul pour le document source soit mémorisé dans votre base de données, une fois qu’il aura eu la réponse du système comme quoi sa demande a été acceptée.

A cet effet, on peut prévoir une entité-type nommée DOCUMENT_SOURCE (ou tout autre nom tel que FICHIER). Une demande fait référence à exactement un document source et un document source est référencé par 0,N demandes :

[DEMANDE]--1,1----()----0,N--[DOCUMENT_SOURCE]

L’entité-type DOCUMENT_SOURCE a pour propriétés :

DocumentSourceId (identifiant)
DocumentSourceNom (exemple : "Dix ans dans une table la vie d’une ligne")
DocumentSourcePath (exemple : "fakepath\Dix_ans_dans_une_table.doc")
Etc.

Au passage, prendre en compte la règle selon laquelle un fichier a un seul format Origine :

[FICHIER]--1,1----()--0,N--[FORMAT_ORIGINE]

Pour en revenir à Raoul il effectue une 2e demande pour l’exemplaire en noir et blanc en priorité basse :

Puis une 3e demande pour les deux exemplaires en priorité normale :

Et il terminera en demandant l’impression d’un exemplaire de « Du rififi à la DSI ».

Merci de me signaler les points qui clochent dans ce scénario...

Par ailleurs, Raoul a effectué des demandes d’impression concernant des documents sources, mais les résultats qui lui seront livrés « là-haut », les documents en sortie, sont sa propriété si je puis dire, or selon votre MCD, on pourrait mélanger ces documents avec ceux de Fernand, on voit l’embrouille qui en résulterait... Pour assurer, il est préférable qu’un document en sortie détermine une demande :

Vous noterez qu’il est préférable de modéliser les priorités, les points de livraison, etc. sous forme d’entités-types. L’attribut DocumentNom a migré vers l’entité-type DOCUMENT_SOURCE (cf. DocumentSourceNom). Les opérations portent sur les documents en sortie.

Envoyé par fullmetalkeke

dans la base de données, les attributs quantité, date, ... sont bien des types spécifiques : integer, datetime, ...

Ouf !

**fsmrel** · 11/08/2013, 19h49

Bonsoir fullmetalkeke,

J'espère ne pas vous avoir heurté avec le MCD que je vous ai proposé. Merci de préciser ce qui pourrait clocher...

**fullmetalkeke** · 12/08/2013, 10h04

Bonjour,

nous avons eu pas mal de réunions ces derniers temps, je n'ai pas eu le temps d'analyser votre réponse.

Pour le moment, j’ai compris qu’un document source (par exemple « Dix ans dans une table la vie d’une ligne ») — ou tout du moins sa référence —, figure sous forme de fichier sur un serveur affecté au service Reprographie. Les agents peuvent demander l’impression d’un ou plusieurs exemplaires de ce document source.

C'est tout à fait ça.

N.B. Raoul ne remplit pas le champ Origine, puisque, je cite :
Un fichier aura un seul et unique Format d'Origine parmi plusieurs possibles : Calque, Doc, Papier, ...

Le champ Origine devra être obligatoirement rempli (les valeurs possibles que j'ai précédemment citées ne sont pour le moment que des exemples), c'est une des contraintes qui m'a été imposée. En voici les principales raisons :
- Le logiciel d'impression que possède la reprographie possède des profils qui permettent d'optimiser l'impression en fonction du type de document.
- Le fait de renseigner ce champ permettra donc au service reprographie d'imprimer ce document sans avoir à vérifier le type de document, le but est d'obtenir un gain de temps à long terme.
- Enfin, si par exemple le fichier d'origine est un calque, la checkbox correspondant au format de sortie "couleur" ne sera pas sélectionnable.
Comme je l'ai dit, il s'agit d'une contrainte, si vous avez des remarques à faire par rapport à celle-ci et aux arguments que j'ai énoncé, n'hésitez pas à m'en faire part.

Je suggère par ailleurs que, si ce n’est fait, le point d’entrée (chemin du fichier) fourni par Raoul pour le document source soit mémorisé dans votre base de données, une fois qu’il aura eu la réponse du système comme quoi sa demande a été acceptée.

L'attribut NomDocument a été remplacé par l'attribut CheminDocument. Il est aisé de pouvoir retrouver le nom du document grâce à ce chemin, le deuxième développeur s'en chargera.

L’entité-type DOCUMENT_SOURCE a pour propriétés :
DocumentSourceId (identifiant)
DocumentSourceNom (exemple : "Dix ans dans une table la vie d’une ligne")
DocumentSourcePath (exemple : "fakepath\Dix_ans_dans_une_table.doc")
Etc.
[DEMANDE]--1,1----()----0,N--[DOCUMENT_SOURCE]

100% d'accord. Mais je n'ai plus besoin, comme je l'ai dit précédemment, du nom du fichier. Seul le path sera nécessaire.

Je suis également d'accord pour le reste du scénario.

Par ailleurs, Raoul a effectué des demandes d’impression concernant des documents sources, mais les résultats qui lui seront livrés « là-haut », les documents en sortie, sont sa propriété si je puis dire, or selon votre MCD, on pourrait mélanger ces documents avec ceux de Fernand, on voit l’embrouille qui en résulterait... Pour assurer, il est préférable qu’un document en sortie détermine une demande

Je n'ai pas tout à fait compris pourquoi les documents pourraient être mélangés. Je n'ai peut-être pas précisé qu'il y aura toujours un "bon de livraison" avec le document imprimé, de ce fait, les documents ne pourront (en tout cas ne devraient) pas pouvoir être confondus.

Vous noterez qu’il est préférable de modéliser les priorités, les points de livraison, etc. sous forme d’entités-types. L’attribut DocumentNom a migré vers l’entité-type DOCUMENT_SOURCE (cf. DocumentSourceNom). Les opérations portent sur les documents en sortie.

Je suis d'accord concernant cette remarque et sur le MCD.

J'ai cependant une question : n'est-il pas possible de "fusionner" les tables "DEMANDE" et "OPÉRATION" ? Dans ma logique je verrai plus quelque chose dans ce genre là :

Bonjour,

nous avons eu pas mal de réunions ces derniers temps, je n'ai pas eu le temps d'analyser votre réponse.