[MCD] gestion parc informatique [Résolu]

[drakuncorp]

Bonjour,
j'aimerais développer une application web basée sur symfony2 concernant la gestion d'un parc informatique. la description est assez simple.

la hotline de cet entreprise gère les matériel.
Il recoivent les nouveaux matériel provenant d'un fournisseurs par lot.

Albert = supérieur hierarchique agent de la HOTLINE (robert)
Robert = agent de la hotline.
Site Grenoble = un succursale situé a grenoble.
Amandine = Responsable Site Grenoble.

1 - Affectation ( sortie de materiel de l'entité mère) à GRENOBLE SITE
ROBERT émet un bon de sortie qui sera ou devra etre validé par son supérieur ALBERT
Aprés validation robert peux procéder au déploiement du matériel sur site GRENOBLE.
arrivé sur site et aprés mise en place fonctionnel du matériel.
AMANDINE , responsable du site GRENOBLE valide le meme bon de sortie émet par ROBERT pour
confirmation de réception du matériel.

2- Un matériel tombe en panne sur site et doit ètre rapatrié a la maison mère : ( entrée de materiel dans la maison mère)
ROBERT emet un bon d'entrée qui témoignera sa prise prise en charge,
Le bon d'entrée doit etre valider par AMANDINE responsable du site GRENOBLE pour monter que le materiel a bien quité son site.
A la réception du materiel , le supérieur ALBERT valide le bon d'entrée pour témoigner le matériel est bien arrivé à destination.


en piece jointe les modele MCD sur lesquel je me suis basé pour créer MCD-gestion de park.
Merci de maider à mettre un ordre dans tout cela car vraiment c'est confue dans ma tète.

Je n'arrive pas à matérialiser les mouvement (entrée sortie) ni a mettre en place la validation

Merci d'avance pour votre aide.
Vous ètes mon tout dernier recours je n'ai nul autre endroit pour exposer ce problème
merci encore

[CinePhil]

en piece jointe les modele MCD

Où ça ?

[drakuncorp]

Bonjour,
excusez moi, pour l’omission.

http://img830.imageshack.us/img830/1015/drakes.png

http://imageshack.us/photo/my-images/830/drakes.png/

[fsmrel]

Bonsoir,


La partie dont vous nous parlez est sans doute noyée dans le diagramme énigmatique, le magma que vous présentez. Normalement vous devriez expliquer le rôle de chaque table, chaque lien et chaque attribut. On est comme en face d’un dictionnaire dans lequel la signification des termes ne serait pas fournie , on reste sur sa faim...

Si c’est trop demander, on peut aussi repartir sur de nouvelles bases, et avant de traiter du matériel commencer par représenter le rôle des intervenants de la hotline et des succursales.

Vous insistez sur le rôle des utilisateurs selon leur appartenance (hotline, succursale), on pourrait donc mettre en œuvre une spécialisation de ces utilisateurs : un utilisateur est soit un utilisateur appartenant à la hotline, soit un utilisateur appartenant à une succursale (en l’occurrence il y aura une contrainte d’exclusion à mettre en œuvre au niveau de la base de données, c'est-à-dire une assertion ou un trigger SQL). Diagramme correspondant :



Manifestement, vous établissez une hiérarchie entre les utilisateurs. On peut représenter cela ainsi (table HIERARCHIE) :



Mais au niveau opérationnel, suite à une distraction de la part du terminaliste, rien n’empêcherait que dans la base de données Albert et/ou Robert (hotline) soient rattachés à Amandine (succursale), ou encore qu’un utilisateur d’une succursale soit rattaché à un utilisateur d’une autre succursale. Pour éviter cela, il faudra mettre en œuvre une contrainte ad-hoc (assertion ou trigger SQL). On peut aussi préférer définir deux hiérarchies parfaitement séparées :



Le cas échéant, vous pouvez imposer au niveau du diagramme qu’une succursale ait bien un responsable (Amandine en ce qui concerne Grenoble) :



Mais au niveau de la base de données, il faudra mettre en œuvre une contrainte (assertion ou trigger SQL) pour garantir qu’un responsable de succursale (Amandine) n’ait pas un de ses collaborateurs pour chef dans la hiérarchie mise en place...

A la limite, si la hiérarchie dans les succursales est limitée à deux niveaux, on peut représenter les choses ainsi (toutefois je ne le recommande pas, car en cas d’évolution il faudra en revenir à une des représentations précédentes) :

Amandine est responsable de la succursale de Grenoble. Le fait est connu grâce à la table RESPONSABLE. Amandine est un utilisateur, le fait est connu par le lien d’héritage (Est un) entre les tables UTILISATEUR et RESPONSABLE. Les collaborateurs d’Amandine sont connus grâce au lien entre les tables UTIL_SUCCURSALE et RESPONSABLE.
Question (a priori à laquelle pour ma part je répondrai affirmativement) : est-il nécessaire de connaître les collaborateurs d’Amandine dans l’agence de Grenoble ?


Comment l’organisation de base de l’entreprise se situe-telle par rapport à ces scénarios ? Peut-on en retenir un ? Proposez-vous une alternative ?

[drakuncorp]

.

Bonsoir a vous ,
il n'est pas nécessaire de connaitre les collaborateurs d'Amandine, car n'intervenant en aucun cas.
L'accent doit ètre mise sur le matériel.
l'intervention d'Amandine ou de son adjoint est simplement nécessaire pour témoigner la réception de matériel déployer sur le meme site.
J'aurai pu mettre n'importe quel personne du temps qu'elle du site concerner.
Mais faut savoir, qu'il peut arriver que les personnes soit muté sur d'autres.
Au lieu de gérer la mutation possible de bon nombre de personne , je la réduit déja , au responsable et peu ètre a son adjointe au cas ou le responsable serait par exemple en congé.

La table user est utilisé ici , a titre de témoignage je dirai si le terme n'est pas trop vague
j'ai juste besoin d'avoir une validation d'une personne que je nommeré, il ne peut ne pas ètre mon supérieur vous savez, exemple ca peut ètre le magasinier tout simplement.Et dès que le technicien arrivé sur site ( ex GRENOBLE) installe et configure le matériel.
Aprés avoir fini , il demande la personne présente ( Amandine ou son adjointe ) de valider son bon c'est tout.
Au départ ( premier validateur ) au milieu le technicien - Arrivée (second validateur)
SOURCE ------ moyen de locomotion ----- DESTINATION
il faut juste une confirmation que ces étapes ont été respectés .

J'ai du encore a un peu modifier le modèle , maintenant je crois qu'il y a une petite confusion entre :

TYPEMATERIEL - MODELE - MARQUE - CARACTERISTIQUE.

je propose :

MATERIEL(1,1) ----- etre du ------- (o,n)MODELE
MODELE(1,1) ------- appartenirt à ---------- (o,n)TYPEMATERIEL
MODELE(1,1) ------- avoir ----------(o,n) MARQUE
MODELE(o,n) --------posséder --------(o,n) CARACTERISTIQUE

excusez moi si le modele est devenu un peu superflux

http://imageshack.us/photo/my-images/830/drakes.png/

[fsmrel]

Bonsoir,

Envoyé par drakuncorp

il n'est pas nécessaire de connaître les collaborateurs d'Amandine.

D’accord. On ne va pas mettre en œuvre de hiérarchie dans l’entreprise et on se contentera de définir par exemple trois populations :

— Les techniciens (Robert, etc.),

— Les personnes de la hotline autorisées à valider les entrées et les sorties (Albert, etc.),

— Les personnes de la succursale autorisées à valider les entrées et les sorties (Amandine, etc.) :




Pour les sorties, en première approche on peut voir les choses ainsi :

Un bon de sortie concerne d’abord un ou plusieurs matériels et un technicien (par exemple Robert).

Une fois que le bon est établi et mis en relation avec Robert dans la base de données (table BON_SORTIE ci-dessous), la personne (Albert) de la hotline habilitée à valider le bon apposera sa signature (table SORTIE_VALIDATION_HOT). Selon le diagramme ci-dessous, du point de vue de la base de données, le bon doit d’abord exister (table BON_SORTIE). L’attribut BonSortieId n’est pas le numéro du bon (représenté par BonNumero), mais un numéroteur maîtrisé non pas par l’utilisateur mais par l’application (implémenté par exemple par un auto-incrément).

La personne (Amandine) de la succursale habilitée à valider le bon appose à son tour sa signature (table SORTIE_VALIDATION_SUC). Selon le diagramme ci-dessous, du point de vue de la base de données, le bon doit d’abord avoir été validé par la hotline (table SORTIE_VALIDATION_HOT).



Selon le diagramme ci-dessus, ça n’est pas forcément la succursale qui détient le matériel qui tamponne le bon de sortie. On pourra mettre en œuvre une contrainte (assertion ou trigger SQL) pour s’assurer que les choses sont correctes. Exemple :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE ASSERTION Assert01 CHECK
      ( NOT EXISTS (
                     SELECT 'Aïe !' 
                     FROM      BON_SORTIE_DETAIL AS x 
                          JOIN SORTIE_VALIDATION_SUC AS y 
                               ON x.BonSortieId = y.BonSortieId
                          JOIN VALIDEUR_SUCC AS z 
                               ON y.ValideurSucId = z.ValideurSucId
                          JOIN MATERIEL_EN_SUCC AS t 
                               ON x.MaterielId = t.MaterielId
                    WHERE z.SuccursaleId <> t.SuccursaleId  
                   )
      ) ;

Cas des entrées :

Même principe que ci-dessus, mais à cause de l’enchaînement chronologique des opérations de validation il y a permutation, c’est la table ENTREE_VALIDATION_SUC qui fait référence à la table BON_ENTREE, tandis que la table ENTREE_VALIDATION_HOT fait référence à la table ENTREE_VALIDATION_SUC. Vue (partielle) correspondante :



Sans aller plus loin, je n’ai traité que des entrées et des sorties, car il faut déjà stabiliser cette partie. Ce nouveau départ vous convient-il ? Faut-il encore remettre tout à plat ?

[drakuncorp]

Bonjour,

En ce moment cela devient de plus en plus clair,

Pour les sorties

Pour une gestion un peu plus simple j’opterais pour un bon de sortie par matériel.

Rien à signaliser pour le cas des entrées.

Bon, es ce que
TECHNICIEN_HOTLINE et VALIDATEUR_HOTLINE et VALIDATEUR_SUCC
Sont des tables en tant que tel une juste une représantation.

Hormis cela je crois que ca me vas

que signifie le ----o|--- sur le schema

Bonne réception

[drakuncorp]

Re bonjour,
au faites,
Je me perds quand j'essaye de fusionner le tout.

Merci à vous

[fsmrel]

Bonsoir,

Envoyé par drakuncorp

En ce moment cela devient de plus en plus clair

Bonne nouvelle !

Envoyé par drakuncorp

Pour une gestion un peu plus simple j’opterais pour un bon de sortie par matériel.

D’accord, mais n'est-ce pas plus lourd pour l’utilisateur ?

Envoyé par drakuncorp

Rien à signaliser pour le cas des entrées.

Vous êtes donc bien d’accord avec la modélisation proposée ?

Envoyé par drakuncorp

Est-ce que TECHNICIEN_HOTLINE et VALIDATEUR_HOTLINE et VALIDATEUR SUCC sont des tables en tant que telles ou une juste une représentation ?

Ce sont évidemment des tables. On crée d’abord la table UTILISATEUR des utilisateurs :

Code SQL :

1
2
3
4
5
6
7
8
9
CREATE TABLE UTILISATEUR
(
        UtilisateurId          INT             NOT NULL
      , UtilisateurNom         VARCHAR(45)     NOT NULL
      , UtilisateurPrenom      VARCHAR(45)     NOT NULL
      , UtilisateurPseudo      VARCHAR(45)     NOT NULL
      , UtilisateurPasse       VARCHAR(45)     NOT NULL
    , CONSTRAINT UTILISATEUR_PK PRIMARY KEY (UtilisateurId)  
) ;

Ensuite les autres tables :

Les techniciens :

Code SQL :

1
2
3
4
5
6
7
8
CREATE TABLE TECHICIEN_HOTLINE
(
        TechnicienId         INT             NOT NULL
    , CONSTRAINT TECHICIEN_HOTLINE_PK PRIMARY KEY (TechnicienId)  
    , CONSTRAINT TECHICIEN_HOTLINE_UTIL_FK FOREIGN KEY (TechnicienId) 
                 REFERENCES UTILISATEUR (UtilisateurId) 
                            ON DELETE CASCADE
) ;

Les valideurs de la hotline :

Code SQL :

1
2
3
4
5
6
7
8
CREATE TABLE VALIDEUR_HOTLINE
(
        ValideurHotId         INT             NOT NULL
    , CONSTRAINT VALIDEUR_HOT_PK PRIMARY KEY (ValideurHotId)  
    , CONSTRAINT VALIDEUR_HOT_UTIL_FK FOREIGN KEY (ValideurHotId) 
                 REFERENCES UTILISATEUR (UtilisateurId) 
                            ON DELETE CASCADE
) ;

Les valideurs des succursales :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE VALIDEUR_SUCC
(
        ValideurSucId         INT             NOT NULL
      , SuccursaleId          INT             NOT NULL
    , CONSTRAINT VALIDEUR_SUCC_PK PRIMARY KEY (ValideurSucId)  
    , CONSTRAINT VALIDEUR_SUCC_UTIL_FK FOREIGN KEY (ValideurSucId) 
                 REFERENCES UTILISATEUR (UtilisateurId) 
                            ON DELETE CASCADE
    , CONSTRAINT VALIDEUR_SUCC_SUCC_FK FOREIGN KEY (SuccursaleId) 
                 REFERENCES SUCCURSALE (SuccursaleId) 
                            ON DELETE CASCADE
) ;

Envoyé par drakuncorp

Que signifie le ----o|--- sur le schéma ?

Considérez le diagramme ci-dessous :


Mathématiquement parlant, la relation entre TECHNICIEN_HOTLINE et BON_SORTIE est une relation fonctionnelle, une application de BON_SORTIE dans TECHNICIEN_HOTLINE : un bon de sortie concerne exactement un technicien, c'est-à-dire un et un seul technicien (sinon ça serait une belle pagaille...) et un technicien peut être concerné par plusieurs bons de sortie.

Considérez maintenant cette partie du diagramme :


Mathématiquement parlant, la relation entre UTILISATEUR et TECHNICIEN_HOTLINE est une injection. Du point de vue de la modélisation, un utilisateur est un parfois un technicien (Robert) et un technicien (Robert encore) est exactement un utilisateur. De même, un utilisateur est parfois un valideur de la hotline (Albert) ou parfois un valideur d’une succursale (Amandine). Selon votre représentation (que je reprends dans la partie droite de l’image ci-dessous), la relation entre UTILISATEUR et TECHNICIEN_HOTLINE est une surjection, c'est-à-dire que du point de vue de la modélisation, un technicien (Robert) fait référence à exactement un utilisateur (qui peut être n’importe quel utilisateur) et un utilisateur est référencé par au moins un technicien. La différence entre ma représentation et la vôtre est celle qui existe entre « être » et « avoir » : il y a plus qu’une nuance ! En réalité, dire qu’un utilisateur est un technicien ou un valideur de la hotline ou un valideur d’une succursale, c’est mettre en œuvre la spécialisation, concept non proposé par MySQL Workbench. A noter que les concepts de spécialisation, généralisation et héritage sont souvent traités dans les forums Schéma, Merise et UML.



Comme précédemment, mathématiquement parlant, la relation entre BON_SORTIE et SORTIE_VALIDATION_HOT est une injection. Du point de vue de la modélisation, il ne s’agit pas en l’occurrence de mettre en œuvre la spécialisation mais plutôt de représenter un état : Si le bon de sortie 123 (BonSortieId = 123) n’a pas été encore validé, il ne figure pas dans la table SORTIE_VALIDATION_HOT. S’il est présent dans cette table, c’est qu’il a été validé.


Structure correspondante des tables :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE BON_SORTIE
(
        BonSortieId         INT             NOT NULL
      , TechnicienId        INT             NOT NULL
      , BonDate             CHAR(10)        NOT NULL 
      , BonHeure            CHAR(05)        NOT NULL
      , BonNumero           INT             NOT NULL
      , BonLibelle          VARCHAR(48)     NOT NULL
    , CONSTRAINT BON_SORTIE_PK PRIMARY KEY (BonSortieId)  
    , CONSTRAINT BON_SORTIE_AK UNIQUE (BonNumero)  
    , CONSTRAINT BON_SORTIE_TECH_FK FOREIGN KEY (TechnicienId) 
                 REFERENCES TECHICIEN_HOTLINE (TechnicienId) 
) ;

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE SORTIE_VALIDATION_HOT
(
        BonSortieId         INT             NOT NULL
      , ValideurHotId       INT             NOT NULL
      , DateValidationHot   CHAR(10)        NOT NULL
      , HeureValidationHot  CHAR(05)        NOT NULL
    , CONSTRAINT SORTIE_VALIDATION_HOT_PK PRIMARY KEY (BonSortieId)  
    , CONSTRAINT SORTIE_VALIDATION_HOT_VALIDEUR_FK FOREIGN KEY (ValideurHotId) 
                 REFERENCES VALIDEUR_HOTLINE (ValideurHotId) 
    , CONSTRAINT SORTIE_VALIDATION_HOT_BON_FK FOREIGN KEY (BonSortieId) 
                 REFERENCES BON_SORTIE (BonSortieId) 
) ;

Je fais observer que la clé primaire de votre propre table SORTIE_VALIDATION_HOT n’est pas bonne, elle doit être réduite à {BonSortieId}.

Je note que vous utilisez systématiquement la surjection. Ainsi, selon vous, chaque matériel a fait (ou fait ou fera !) l’objet d’une panne. Ne pensez-vous pas qu’une application (toujours au sens mathématique) serait plus appropriée ? Dans l’exemple ci-dessous, si l’on veut signifier que les techniciens ne sont pas nécessairement tous concernés par un bon de sortie (cas par exemple des nouveau embauchés, des techniciens pour lesquels le ménage a été fait dans les bons de sortie), on décoche la case Mandatory dans l’onglet BON_SORTIE_TECH_FK :

[drakuncorp]

Bonjour,
Certainement que c'est lourd comme vous le disiez, mais je ne pense pas qu'il y aura sortie de nombre de matériel assez considérable par jour je dirai.

Je suis d'accord avec la modélisation proposé mais pour un bon par matériel pour la sortie ainsi qu'à l'entrée.

Voici le schéma modifié
en passant j'aimerais savoir c'est quoi le mandatory
, comment , quand et ou l'utiliser

[fsmrel]

Bonsoir,

Envoyé par drakuncorp

Je suis d'accord avec la modélisation proposée mais pour un bon par matériel pour la sortie ainsi qu'à l'entrée.

D’accord, pas de problème.

Envoyé par drakuncorp

que signifie le ----o|--- sur le schema

J’ai oublié de préciser une chose hier, il s’agit d’un lien identifiant, en conséquence de quoi la table TECHNICIEN_HOTLINE a pour clé primaire {TechnicienId} qui est aussi clé étrangère et fait référence à la clé primaire {UtilisateurId} de la table UTILISATEUR :

Envoyé par drakuncorp

Je me perds quand j'essaye de fusionner le tout.

Plutôt que de présenter un diagramme ressemblant à un gros pavé bien indigeste, le mieux est de procéder par vues.

Vue SORTIES :



Vue ENTRÉES :



Maintenant, si les bons de sortie et les bons d’entrée ne se différencient que par leur type, vous pouvez procéder à une généralisation de BON_ENTREE et BON_SORTIE en BON :


Attention, le diagramme tend vers l’illisible : il serait opportun de mettre les vues en œuvre (cf. les deux diagrammes précédents). Je rappelle que pour cela on crée un nouveau diagramme (« Add diagram ») :




Le nouveau diagramme « EER diagram » peut être renommé à l’aide de la touche F2.

Ensuite, une fois activé le nouveau diagramme, on clique sur les noms des tables à sélectionner et par drag drop on les « tire » et on les pose là où on veut dans le schéma :




Au besoin, on peut retirer du schéma une table qu’on a posée à tort. Faire DELETE de la table, mais en utilisant ensuite le bouton « Keep » pour ne pas la détruire...




Je viens de découvrir votre dernier diagramme. Je regarderai cela de plus près.

A propos de « Mandatory » :

Si par exemple une règle disait que tout matériel fait l’objet d’un bon, on cocherait la case « Mandatory ». Au contraire, si ça n’est pas tous les matériels, on décoche la case.

[drakuncorp]

Bonjour,
Question:

le champ BonNumero : il sert a quoi maintenant,
La table MATERIEL EN SUCC il sert aussi à quoi.

(Identifiying relationchip et non identifying relationchip on les utilisent quand)



Merci a vous

[fsmrel]

Bonsoir,


Concernant votre diagramme :

La table que nommez « utilisateurs » est en réalité la table des utilisateurs. En français, son nom doit être au singulier et en majuscules, à savoir « Utilisateur » (ou en lettres capitales : « UTILISATEUR », ce que je continuerai du reste à faire, surtout pour des raisons de lisibilité). Même chose pour les autres tables : ENTITE, MATERIEL, etc. Pour éviter les problèmes avec les langages de programmation et les SGBD, on évite quand même l’emploi des accents.

Sur le lien connectant UTILISATEUR et VALIDEUR_SUCC, il y a un Mandatory en trop (|| au lieu de |o).

Envoyé par drakuncorp

le champ BonNumero : il sert a quoi maintenant ?

BonNumero n’est pas un nom de champ, mais un nom d’attribut (ou de colonne en SQL, comme avec MySQL Workbench).
Cela dit, les attributs dont les noms figurent dans l’en-tête (header) d’une table correspondent à des données qui peuvent être naturelles ou artificielles. Voyez la table UTILISATEUR Le nom d’un utilisateur, son prénom, son pseudo, sont des données naturelles, leur fonction est de décrire l’utilisateur, ces données sont modifiables par celui ou celle qui met à jour la base de données. L’attribut Id (UtilisateurId dans mes diagrammes) pour sa part ne décrit rien, il est purement artificiel, son rôle est de garantir une contrainte d’unicité, à savoir que deux lignes n’existeront pas en double dans la table, donc que l’algèbre relationnelle ne sera pas prise en défaut (le corps (body) d’une table est un ensemble, tout comme du reste l’en-tête). C’est pour cela que vous avez défini la clé de la table UTILISATEUR à partir de l’attribut Id. Etant donné que cet attribut ne décrit rien, qu’il est purement technique, il est inconnu de l’utilisateur final, et il n’y a aucune raison pour qu’il change de valeur.
Pour la table BON, c’est la même chose. L’attribut Id (BonId dans mes diagrammes) est artificiel, non modifiable, sans signification et inconnu de l’utilisateur, il sert pour la clé de la table. Je suis parti du principe que l’utilisateur a quand même certainement besoin de numéroter les bons : c’est à cet effet que j’ai mis en œuvre l’attribut BonNumero : l’utilisateur en fait ce qu’il veut, simplement on garantit quand même le principe de l’unicité en faisant de cet attribut une clé alternative (clause SQL UNIQUE) :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE BON
(
        BonId               INT             NOT NULL
      , TechnicienId        INT             NOT NULL
      , MaterielId          INT             NOT NULL
      , BonNumero           INT             NOT NULL
      , BonDate             DATE            NOT NULL 
      , BonHeure            TIME            NOT NULL
      , BonLibelle          VARCHAR(48)     NOT NULL
    , CONSTRAINT BON_PK PRIMARY KEY (BonSortieId)  
    , CONSTRAINT BON_AK UNIQUE (BonNumero)  
    , CONSTRAINT BON_TECH_FK FOREIGN KEY (TechnicienId) 
                 REFERENCES TECHICIEN_HOTLINE (TechnicienId) 
    , CONSTRAINT BON_MATERIEL_FK FOREIGN KEY (MaterielId) 
                 REFERENCES MATERIEL (MaterielId) 
) ;

Cela dit, si ça ne gêne pas l’utilisateur de ne pas avoir la maîtrise de la numérotation, alors vous pouvez faire l’économie de BonNumero. Il pourra voir BonId mais avec interdiction d’en changer la valeur.

Vous pouvez aussi lire ce que j’ai écrit au sujet des clés primaires.

Envoyé par drakuncorp

La table MATERIEL_EN_SUCC sert à quoi ?

Je suis parti du principe que les matériels n’étaient pas tous présents dans les succursales, cas des matériels affectés à la hotline, ou arrivant de chez le fournisseur ou n’étant plus en service. A vous de voir : si tout matériel est affecté à ce que vous appelez une entité, alors la table MATERIEL_EN_SUCC peut disparaître.

Envoyé par drakuncorp

Identifiying relationship et non identifying relationship on les utilise quand ?

Identifying relationship correspond à ce que l'on appelle l’identification relative, dont on se sert entre autres pour traduire la généralisation/spécialisation. Dans ce cas, la clé primaire de chaque table spécialisée (TECHNICIEN_HOTLINE, VALIDEUR_HOTLINE, VALIDEUR_SUCC) est aussi clé étrangère par rapport à la table contenant les données communes (UTILISATEUR) : revoyez les structures tabulaires que je vous ai déjà présentées.

L’identification relative sert aussi pour l’identification des tables dont les données ont été externalisées depuis une autre table : par exemple, les lignes d’une facture représentent une propriété multivaluée de la facture, c’est à la vie à la mort (cf. la relation de composition en UML)... La table des lignes de facture est en toute logique identifiée relativement à la facture.
Voyez par exemple le 4e exemple de Dénormalisation vs amélioration (optimisation) ou encore ici et là.

[drakuncorp]

Envoyé par fsmrel

Bonsoir,


Concernant votre diagramme :

La table que nommez « utilisateurs » est en réalité la table des utilisateurs. En français, son nom doit être au singulier et en majuscules, à savoir « Utilisateur » (ou en lettres capitales : « UTILISATEUR », ce que je continuerai du reste à faire, surtout pour des raisons de lisibilité). Même chose pour les autres tables : ENTITE, MATERIEL, etc. Pour éviter les problèmes avec les langages de programmation et les SGBD, on évite quand même l’emploi des accents.

Sur le lien connectant UTILISATEUR et VALIDEUR_SUCC, il y a un Mandatory en trop (|| au lieu de |o).

C'est bon je l'ai corrigé


BonNumero n’est pas un nom de champ, mais un nom d’attribut (ou de colonne en SQL, comme avec MySQL Workbench).
Cela dit, les attributs dont les noms figurent dans l’en-tête (header) d’une table correspondent à des données qui peuvent être naturelles ou artificielles. Voyez la table UTILISATEUR Le nom d’un utilisateur, son prénom, son pseudo, sont des données naturelles, leur fonction est de décrire l’utilisateur, ces données sont modifiables par celui ou celle qui met à jour la base de données. L’attribut Id (UtilisateurId dans mes diagrammes) pour sa part ne décrit rien, il est purement artificiel, son rôle est de garantir une contrainte d’unicité, à savoir que deux lignes n’existeront pas en double dans la table, donc que l’algèbre relationnelle ne sera pas prise en défaut (le corps (body) d’une table est un ensemble, tout comme du reste l’en-tête). C’est pour cela que vous avez défini la clé de la table UTILISATEUR à partir de l’attribut Id. Etant donné que cet attribut ne décrit rien, qu’il est purement technique, il est inconnu de l’utilisateur final, et il n’y a aucune raison pour qu’il change de valeur.
Pour la table BON, c’est la même chose. L’attribut Id (BonId dans mes diagrammes) est artificiel, non modifiable, sans signification et inconnu de l’utilisateur, il sert pour la clé de la table. Je suis parti du principe que l’utilisateur a quand même certainement besoin de numéroter les bons : c’est à cet effet que j’ai mis en œuvre l’attribut BonNumero : l’utilisateur en fait ce qu’il veut, simplement on garantit quand même le principe de l’unicité en faisant de cet attribut une clé alternative (clause SQL UNIQUE) :

Code SQL :

Cela dit, si ça ne gêne pas l’utilisateur de ne pas avoir la maîtrise de la numérotation, alors vous pouvez faire l’économie de BonNumero. Il pourra voir BonId mais avec interdiction d’en changer la valeur.

Pourquoi un utilisateur aura t-il besoin d'insérer des numéros de bon, je laisse cela a BonID

Vous pouvez aussi lire ce que j’ai écrit au sujet des clés primaires.


Je suis parti du principe que les matériels n’étaient pas tous présents dans les succursales, cas des matériels affectés à la hotline, ou arrivant de chez le fournisseur ou n’étant plus en service. A vous de voir : si tout matériel est affecté à ce que vous appelez une entité, alors la table MATERIEL_EN_SUCC peut disparaître.

Vous êtes en plein dans mon schéma, c'est exactement le cas, les matériels ne son pas tous présent dans les succursales, ils peuvent êtres affectés à la hotline ou bien neuves et encore hors service.

Maj faites !!!

Identifying relationship correspond à ce que l'on appelle l’identification relative, dont on se sert entre autres pour traduire la généralisation/spécialisation. Dans ce cas, la clé primaire de chaque table spécialisée (TECHNICIEN_HOTLINE, VALIDEUR_HOTLINE, VALIDEUR_SUCC) est aussi clé étrangère par rapport à la table contenant les données communes (UTILISATEUR) : revoyez les structures tabulaires que je vous ai déjà présentées.

L’identification relative sert aussi pour l’identification des tables dont les données ont été externalisées depuis une autre table : par exemple, les lignes d’une facture représentent une propriété multivaluée de la facture, c’est à la vie à la mort (cf. la relation de composition en UML)... La table des lignes de facture est en toute logique identifiée relativement à la facture.
Voyez par exemple le 4e exemple de Dénormalisation vs amélioration (optimisation) ou encore ici et là.

schéma mise à jour

Vous êtes en plein dans mon schéma, c'est exactement le cas, les matériels ne son pas tous présent dans les succursales, ils peuvent êtres affectés à la hotline ou bien neuves et encore hors service.

Maj faites !!!
La on est okay!

[fsmrel]

Bonsoir,

Envoyé par drakuncorp

Pourquoi un utilisateur aura t-il besoin d'insérer des numéros de bons ?

Le mieux serait quand même de lui poser la question, il a son mot à dire ! Si dans mon entreprise, en tant que qu’informaticien, je prenais l’initiative de mettre en oeuvre un système de numérotation des factures, les comptables me demanderaient de me mêler de ce qui me regarde et ils auraient bien raison...


Note : certaines de vos tables comportent un attribut de type DATE quand il devrait être du type TIME (HeureValidation_xxx). En plus, cet attribut n’est pas toujours présent. En fonction de votre SGBD, vous pourriez sans doute utiliser le type TIMESTAMP (ou équivalent) afin de gérer à la fois la date et l’heure.

[drakuncorp]

comme vous lavait dit , c'est juste un choix, ce sont des attribut que e pourrai changer aprés ainsi que les types.

si cette vue est okay pourrait on passer a d'autres vue s'il vous plait bien par exemple materiel modele marque typemateriel caracteristique.

[fsmrel]

Bonjour,

Envoyé par drakuncorp

comme vous lavait dit , c'est juste un choix, ce sont des attribut que e pourrai changer aprés ainsi que les types.

si cette vue est okay pourrait on passer a d'autres vue s'il vous plait bien par exemple materiel modele marque typemateriel caracteristique.

Quelle est la position de l’utilisateur vis-à-vis de la numérotation des bons ?

Je vous ai fourni un exemple de vue avec les entrées/sorties, j’attends maintenant que vous fournissiez les règles de gestion concernant les modèles, etc., ainsi que (à titre d'exercice) la vue relative à ce 2e thème.

[drakuncorp]

gérer la tracabilité du matériel,
cela me permettra aprés en tant réel de voir l'état des matériels, le matériel restant d'un lot nouvellement acquis.

les valideur leur tache sera limité a la validation , consultations.

Seul le technicien émet les bons

il y aura trois profils je dirai.
les validateurs, les consultants simple et les émetteurs de bon( seuls les techniciens ou personne étant habilité).
Si vous avez une suggestions je suis ouverts a toutes proposition.

J'ai eu le temps d'exploiter les vues , que vous m'aviez appris plus haut (merci encore en passant)

bon voici les vues :


LES LOTS



MAINTENANCE



MATERIEL ( la ou je suis encore un peu confus , attendant votre aide)



PRET


REPARATON


C'est tout , en attente avis , correction / suggestions;
Merci à vous

[drakuncorp]

Une question:
Et si je voulais restreindre la validation pour les succursales,

Amandine ne peut valider que les bon de la succursale à laquelle elle est rattaché ( GRENOBLE)

Et Charlotte ne peut valider que ses bons (Succursale d'Aubervillier)

Je ne vois pas comment je peux avoir cela car lors de l'établissement du bon, il n'y a pas a mentionner la destination, cela n'est fait qu'aprés validation du Bon par le Respo.

le technicien émet le bon(ex N° 123) pour Grenoble,
Albert son sup le verra la liste des bon émi et valide le bon
Charlotte ne verra pas le bon (N° 123)
Par contre Amandine si vu que le matériel est destiné a son site.

Merci a vous toujours

[fsmrel]

Bonsoir Drakuncorp,

Envoyé par drakuncorp

gérer la traçabilité du matériel, cela me permettra après en temps réel de voir l'état des matériels, le matériel restant d'un lot nouvellement acquis.

Si la table MATERIEL_EN_SUCC est utilisée non seulement pour savoir quels matériels sont dans quelles succursales, mais aussi dans n’importe quelle entité de votre groupe (y-compris la hotline), tout va bien, les matériels disponibles correspondent alors à ce qu’il y a dans la table MATERIEL moins ce qu’il y a dans la table MATERIEL_EN_SUCC (en passant, il faudrait quand même renommer celle-ci, par exemple en MATERIEL_AFFECTATION (ou MATERIEL_AFFECTE, etc.)). Si la table MATERIEL_EN_SUCC est utilisée seulement pour les succursales, il faudra prévoir (au moins) une autre table permettant de savoir quels matériels sont affectés aux autres entités, sinon on ne saura pas déterminer le stock non affecté.

Envoyé par fsmrel

Le mieux serait quand même de lui poser la question, il a son mot à dire ! Si dans mon entreprise, en tant que qu’informaticien, je prenais l’initiative de mettre en oeuvre un système de numérotation des factures, les comptables me demanderaient de me mêler de ce qui me regarde et ils auraient bien raison...

Vous n’avez pas répondu à ma question. C’est le maître d’ouvrage qui valide le choix de la numérotation qui a été fait par le concepteur et la maîtrise d’oeuvre. Je pose la question autrement : êtes-vous le représentant de la maîtrise d’ouvrage ?

Envoyé par drakuncorp

Amandine ne peut valider que les bon de la succursale à laquelle elle est rattaché ( GRENOBLE)

Et Charlotte ne peut valider que ses bons (Succursale d'Aubervillier)

Je ne vois pas comment je peux avoir cela car lors de l'établissement du bon, il n'y a pas a mentionner la destination, cela n'est fait qu'aprés validation du Bon par le Respo.

le technicien émet le bon(ex N° 123) pour Grenoble,
Albert son sup le verra la liste des bon émi et valide le bon
Charlotte ne verra pas le bon (N° 123)
Par contre Amandine si vu que le matériel est destiné a son site.

Si je comprends bien, quand Albert (valideur de la hotline) valide le bon de sortie, il doit mentionner la succursale destinataire. Dans ces conditions, il faut établir à cet effet un lien entre les tables SORTIE_VALIDATION_HOT (attribut SuccursaleDestinataireId) et SUCCURSALE :


Ainsi, grâce à la présence de l’attribut SuccursaleDestinataireId, on peut ne présenter à Amandine que les bons qui concernent sa succursale (Grenoble), même chose pour Charlotte.

Pour prévenir d’éventuelles erreurs de programmation, il serait prudent de mettre en œuvre une contrainte garantissant la règle selon laquelle la succursale désignée par Albert et celle du valideur (Amandine) ne font qu’une :

Code SQL :

1
2
3
4
5
6
7
8
9
10
11
12
----------------------------------------------------------------------------------------------------
-- Le valideur en succursale doit valider seulement les bons de sortie qui le concernent
----------------------------------------------------------------------------------------------------
CREATE ASSERTION Assert02 CHECK
      ( NOT EXISTS (
                     SELECT ''
                     FROM         SORTIE_VALIDATION_HOT AS x
                            JOIN  SORTIE_VALIDATION_SUC AS y ON x.BonSortieId = y.BonSortieId
                            JOIN  VALIDEUR_SUCC AS z ON y.ValideurSucId = z.ValideurSucId
                     WHERE x.SuccursaleId <> z.SuccursaleId  
                    )
       ) ;

Voilà pour ce soir, bon dimanche.