gestion parc informatique

**drakuncorp** · 11/12/2011, 02h49

Bonsoir,

Oui , je suis le maitre d'ouvrage.

Choisir la destination ne serait t'il pas mieux au moment de l'établissement du BOn par le technicien vu que c'est lui qui est à la source de celle ci.

Maj table materiel_en_succ renommé et elle n'est pas utilisée que pour les succursale mais pour tous.(c'est mieux selon moi)

yep, Bon Dimanche à vous de même.
Merci

**fsmrel** · 12/12/2011, 14h48

Bonjour Drake,

Envoyé par drakuncorp

Choisir la destination ne serait t'il pas mieux au moment de l'établissement du bon par le technicien vu que c'est lui qui est à la source de celle ci.

Il y a un problème. Vous aviez écrit auparavant :

Envoyé par drakuncorp

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.

C’est bien pour cela que j’ai écrit qu’il fallait établir le lien entre les tables SUCCURSALE et SORTIE_VALIDATION_HOT. Il faudrait éviter de modifier les règles du jeu en cours de route.

=>

Fixez la règle une bonne fois pour toutes, en précisant formellement à quel moment on a connaissance de la succursale (l’entité) destinataire : avant ou au moment de la validation du bon de sortie.

A propos des vues

Vous avez fourni les vues correspondant aux différents thèmes pris en compte dans votre modèle : c’est une excellente chose, car on a là une bonne base pour travailler sans se noyer dans la masse des tables. Toutefois, vous n’avez pas fourni les règles de gestion des données.

Il faudrait que pour chaque vue vous définissiez les concepts et ce que vivent les tables correspondantes. Par exemple, prenons le cas de la vue LOTS : qu’est-ce qu’un lot ? On est dans une tombola ? Qu’est-ce qu’un tiers ? Quel est le rôle des relations entre les lots et les tiers ? Racontez et illustrez la vie de tout ce petit monde comme vous l’avez fait fort justement pour les bons d'entrée et de sortie, en ayant décrit le rôle que jouent Albert, Robert, Amandine et compagnie dans cette affaire.

Si vous procédez ainsi, on pourra étudier les problèmes non encore identifiés que vous vous posez avec la vue MATERIELS : pour le moment on sait seulement que vous ressentez une certaine confusion...

**drakuncorp** · 12/12/2011, 15h31

parfaitement,
Je me suis en mêlé les pinceaux a ce niveau.

Je vais remet les vues avec les règles de gestions cette fois.

Pour cette gestion ;
On a connaissance de la succursale à l'établissement du bon par le technicien , avant validation Hotline;( albert ne fais que visualiser et valider).

Merci.
LOT

MAINTENANCE

ENTITE

ENTREES

BON

Bonne Réception

**fsmrel** · 13/12/2011, 04h03

Bonsoir,

Vous posez la question :

Vu que la table BON regroupe les entrées et les sorties, comment savoir quel bon est destiné à une entrée ou à une sortie (par exemple si deux techniciens rédigent en même temps des bons d’entrée et de sortie) ?

Un bon B1 fait par exemple référence à un matériel M1 figurant dans la table MATERIEL. Si M1 est affecté à une entité, alors il figure aussi dans la table MATERIEL_EN_SUCC et inversement, si M1 n’est pas affecté alors il ne figure pas dans cette table. On peut alors inférer que si M1 figure dans la table MATERIEL_EN_SUCC alors le bon correspond à une entrée, tandis que si M1 n’y figure pas alors il s’agit d’une sortie. Néanmoins, si cela vous rassure, on peut ajouter à la table BON un attribut (appelons-le BonType) prenant soit la valeur 'entrée' soit la valeur 'sortie' selon que le bon correspond à une entrée ou à une sortie. La vérification de la validité de la valeur prise par l'attribut BonType est à faire directement au niveau de la table (contrainte BON_TYPE_VAL ci-dessous) :

Code SQL :

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
CREATE TABLE BON
(
        BonId               INT             NOT NULL
      , TechnicienId        INT             NOT NULL
      , MaterielId          INT             NOT NULL
      , EntiteId            INT             NOT NULL
      , BonType             CHAR(06)        NOT NULL
      , BonDate             DATE            NOT NULL 
      , BonHeure            TIME            NOT NULL
      , BonLibelle          VARCHAR(48)     NOT NULL
    , CONSTRAINT BON_PK PRIMARY KEY (BonId)  
    , CONSTRAINT BON_TYPE_VAL CHECK (BonType IN ('entrée', 'sortie')) 
    , CONSTRAINT BON_TECH_FK FOREIGN KEY (TechnicienId) 
                 REFERENCES TECHICIEN_HOTLINE (TechnicienId) 
    , CONSTRAINT BON_MAT_FK FOREIGN KEY (MaterielId) 
                 REFERENCES MATERIEL (MaterielId)
    , CONSTRAINT BON_ENT_FK FOREIGN KEY (EntiteId) 
                 REFERENCES ENTITE (EntiteId)
)  ;

Par ailleurs, pour garantir la cohérence de votre système vous devrez programmer deux contraintes :

La 1re pour garantir que la validation par Albert d’un bon de sortie correspond bien à une sortie :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE ASSERTION Assert031 CHECK
      ( NOT EXISTS (
                     SELECT *
                     FROM         BON AS x 
                            JOIN  SORTIE_VALIDATION_HOT AS y ON x.BonId = y.BonSortieId
                     WHERE x.BonType <> 'sortie'  
                   )
      ) ;

La 2e (même principe) pour garantir que la validation par Amandine d’un bon d’entrée correspond bien à une entrée :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE ASSERTION Assert032 CHECK
      ( NOT EXISTS (
                     SELECT *
                     FROM         BON AS x 
                            JOIN  ENTREE_VALIDATION_SUC AS y ON x.BonId = y.BonEntreeId
                     WHERE x. BonType <> 'entrée'  
                   )
      ) ;

En passant, la contrainte Assert02 change :

Code SQL :

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

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

Vue BONS :

Je regarderai la suite plus tard.

**drakuncorp** · 13/12/2011, 13h57

Bonjour fsmrel,
vu les assertions créer plus haut, et avec les modifications que le schéma a subi, ne serait il pas mieux de faire un récap des contraintes d'assertions.

et voici les regles de gestion restante.
Merci et bonne fin de journée à vous
MATERIEL

PANNE

PRET

REPARATIOn

SORTIE

**fsmrel** · 15/12/2011, 04h24

Bonsoir,

Dans mon précédent message, j’ai fourni un diagramme (vue BONS) concernant à la fois les entrées et les sorties. Dans votre dernier message, la vue SORTIE montre que les sorties sont isolées des entrées. Quelle est votre position :

Une seule table BON (comme dans ma vue BONS) ?

Une table des bons pour les entrées et une 2e table des bons pour les sorties ?

Cela conditionne l’existence des assertions que j’ai proposées pour les sorties (outre celles qui concerneraient les entrées).

A propos des lots et des matériels

Je lis dans votre message du 13/12/2011 :

« Je ne sais pas comment agencer tout cela pour que, si j’ai le modèle, je puisse avoir toutes les infos dérivantes, à savoir marque, caractéristique, type de matériel, pour que les informations soient concordantes. »

Autrement dit, vous souhaitez éviter les redondances, donc les incohérences inhérentes.

Vous avez mis en œuvre une table TYPE_MATERIEL_MARQUE, qui fournit une sorte de catalogue des types de matériel par marque. Si donc la table MODELE fait référence à cette table, on connaît sans ambiguïté la marque et le type de matériel pour chaque modèle. Concernant la caractéristique pourquoi la table MODELE ne référencerait-elle pas directement la table CARACTERISTIQUE ?

On évite ainsi les redondances. Par exemple, pour le modèle d’écran XY2540E, à savoir l’écran 21 pouces de la marque Zigomar avec l’organisation suivante des tables :

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
TYPE_MATERIEL {TypeMaterielId    TypeMaterielLibelle}     MARQUE{MarqueId    MarqueNom}
                            1    Ecran                                  1    Merbleck 
                            2    Imprimante                             2    Zigomar
                            3    Graveur DVD 

TYPE_MATERIEL_MARQUE {TypeMaterielId    MarqueId}
                                   1           2
                                   3           2
                                   2           1

CARACTERISTIQUE {CaracteristiqueId    CaracteristiqueLibelle    Unite}
                                 1    RAM 512                       2
                                 3    21 pouces                     1

MODELE {ModeleId    ModeleNom    TypeMaterielId    MarqueId    CaracteristiqueId}
               1    XY2540E                   1           2                    3

A propos de la composition des lots :

Selon votre diagramme, un lot fait référence à seul tiers.

Par ailleurs, vous proposez les scénarios suivants :

S1) Un lot est homogène, c'est-à-dire composé d’un seul type de matériel. Par référence au diagramme, il n’y a qu’un seul fournisseur.

S2) Un lot peut être hétérogène, c'est-à-dire qu’il peut être composé de plusieurs types de matériels (par exemple PC et écrans). Par référence au diagramme, il n’y a qu’un seul fournisseur.

S3) Non seulement un lot peut être hétérogène, mais en plus il peut être multi-tiers, contrairement au diagramme.

Ce à quoi, pour des raisons de complétude on peut ajouter le scénario suivant :

S4) Lot multi-utilisateurs mais homogène (un seul type de matériel).

Quel scénario a votre faveur ?

Avec les quelques information dont je dispose, je verrais bien ma mise en oeuvre du scénario S3, de la façon suivante :

Un lot peut être composé de matériels de modèles différents et fournis par des tiers différents.

Exemple :

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
MODELE {ModeleId    ModeleNom    TypeMaterielId    MarqueId    CaracteristiqueId}
               1    XY2540E                   1           2                    3 
               2    DX8000MT                  1          47                    7 
               3    DX2000MT                  1          47                    7 

TIERS {TiersId    TiersRaisonSociale}        LOT {LotId    LotLibelle    LotDateReception}
             1    Dac & Blanche                       1    Lot 1         2011-12-05
             2    Edmond et fils                      2    Lot 2         2011-12-10

LOT_TIERS {ModeleId    LotId    TiersId    Quantite}
                  1        1          1          10
                  2        1          1           5
                  1        2          1           7
                  2        2          2           8
                  3        2          2           5
                  1        1          2           6

MATERIEL {MaterielId    ...    ModeleId    LotId    TiersId}
                   1                  1        1          1

Mais je manque de billes, peut-être cela ne convient-il pas pour votre application....

**drakuncorp** · 15/12/2011, 11h56

Bonjour,

J'ai divisé en deux vues juste pour mieux voir mais dans mon avant dernier message il y a la vue bon qui regroupe les deux.Pour le moment concernant les bon c'est bien clair à moins que vous n'ayez des choses à y rajouter.

Pour le matériel:
Pourquoi MarqueID et TypematérielID se retrouve dans la table MODELE.

En plus Un modele Peut avoir plusieur Caractéristiques à savoir :
Ex DX2000MT : taille disque dur, nombre et taille de chaque barette, processeur etc... alors si la clé caractéristiqueID est dans modele alors ce paramètre restera figé selon moi.

Il y a plusieurs TIERS,
Ce modele convient bien car aprés tout on peut choisir le meme tiers pour les autres élément constituant le lot, c'est okay!
Meme question pourquoi Tiersid figure dans la table matériel.
Pourquoi un groupe de clé migre dans une table.

alors ce que je peux retenir de tout cela, c'est qu'un matériel sera identifié en fonction du lot auquel il appartient!!!

**fsmrel** · 23/12/2011, 00h32

Bonsoir,

Envoyé par drakuncorp

J'ai divisé en deux vues juste pour mieux voir mais dans mon avant dernier message il y a la vue bon qui regroupe les deux.

D’accord, mais votre vue BON est incomplète, car il manque le lien entre la table des bons et la table des entités, ce qui provoque l’absence de l’attribut EntiteId dans l’en-tête de la table des bons. En outre, il y manque aussi l’attribut BonType : comparez avec la vue qui figure dans mon message #24.

Envoyé par drakuncorp

Pourquoi MarqueID et TypematerielID se retrouvent dans la table MODELE ?

Dans votre vue MATERIEL, vous avez défini une table de relation (typemateriels_marques) entre les tables marques et typemateriels. La clé primaire de la table typemateriels_marques (table nommée TYPE_MATERIEL_MARQUE dans le diagramme que je vous ai fourni) est composée des deux attributs TypematerielId et MarqueId. Si donc une autre table (MODELE par exemple) fait référence à cette table, automatiquement elle comporte une clé étrangère composée des deux attributs TypematerielId et MarqueId, ce qui revient à dire qu’un modèle fait référence à une marque d’une part, à un type de matériel d’autre part.
Par exemple, si le modèle est "Color LaserJet Enterprise CP5525xh", il fait référence à la marque « HP » et au type de matériel disons « Imprimante couleur ».

Je rappelle en passant que la modélisation que j’ai proposée a pour objet l’absence de redondance.

Envoyé par drakuncorp

Un modèle peut avoir plusieurs Caractéristiques à savoir :
Ex DX2000MT : taille disque dur, nombre et taille de chaque barrette, processeur etc. alors si la clé caractéristiqueID est dans modele alors ce paramètre restera figé selon moi.

De ce que je comprends, « DX8000MT » serait un modèle d’ordinateur, donc un ordinateur de ce modèle a des composants dont les caractéristiques sont la taille pour le composant disque dur, la taille pour le composant barrette, etc. Cela pose le problème du matériel composé d’autres matériels.

En conséquence, je propose que l'on spécialise ainsi les modèles de matériels :

1) Modèles composés de plusieurs matériels (fondamentalement les modèles d’ordinateur), avec plusieurs caractéristiques ;

2) Modèles d’un seul type de matériel (disque sur, écran, etc.), avec une ou plusieurs caractéristiques (la diagonale pour un écran, la capacité et la vitesse de rotation pour un disque, etc.)

On aurait donc une table MODELE pour tout ce qui est commun aux deux types de modèles, plus deux tables spécialisées :

MODELE_MULTI pour les modèles composés de plusieurs matériels ;

MODELE_MONO pour les modèles mono type de matériel (écran, disque dur, impimante, etc.)

Dans le diagramme ci-dessous, la table TYPE_MAT_CAR correspond à votre table typesmateriels_caracteristiques.

La table MODELE_COMPOSITION permet de décrire la composition d’un modèle d’ordinateur (capacité du disque dur, vitesse de rotation du disque dur, mémoire RAM, etc.)

La table MODELE_TYPE permet de préciser le type d’ordinateur : UC, portable, tablette, etc.

La table MODELE_MONO_CAR permet d’associer une ou plusieurs caractéristiques à un modèle de matériel monotype.

Je ne sais pas si cela vous convient : j’attends vos remarques. Si quelque chose ne va pas, merci d’illustrer les raisons à l’aide d’exemples exhaustifs.

Envoyé par drakuncorp

Ce que je peux retenir de tout cela, c'est qu'un matériel sera identifié en fonction du lot auquel il appartient!!!

Certainement pas. En effet, la table MATERIEL a pour clé primaire, c'est-à-dire pour identifiant {MaterielId}. Simplement, un matériel fait référence à un modèle, au lot dont il provient et au tiers correspondant, ce qui n’est quand même pas pareil.

Quelle est la signification de l"attribut unite de votre table caracteristiques ?

Je reprendrai le reste (dont la liste des assertions) un peu plus tard.

**drakuncorp** · 23/12/2011, 18h16

Bonsoir,

Ce schéma est bien clair, détaillé et me convient pour le cas MODELE , et avec cela je n'ai plus besoin de l'attribut unite dans la table caractéristique.

Juste une question: pour la concaténation des clés des tables:
Pour TYPE_MAT_CAR, MODELE_COMPOSITION, MODELE_MULTI, MODELE_MONO, MODELE_MONO_CAR ...
si je créer des id spécifiques pour ces tables ex pour TYPE_MAT_CAR j'aurais : id en PK, typematerielid,caracteristiqueid en attribut

quel sont les avantages de ce procéder, ou les inconvénients pourrai vous m'expliquez la différence de cette méthode et du votre.

**fsmrel** · 26/12/2011, 03h12

Bonsoir,

Envoyé par drakuncorp

Si je crée des id spécifiques

C'est-à-dire des clés singletons. Le diagramme deviendrait donc le suivant :

Table MODELE_MONO

La table MODELE_MONO aurait pour clé primaire {ModeleMonoId} au lieu de {ModeleId}. Il n’y a que des inconvénients à effectuer une telle substitution. En effet, cela conduirait à devoir définir un attribut supplémentaire ModeleMonoId pour cette table, et de toutes façons devoir définir {ModeleId} comme clé alternative (alternate key, mickey «

», faisant l’objet d’une contrainte UNIQUE lors de la définition en SQL de la table), puisque deux lignes de la table n’ont pas le droit d’avoir la même valeur pour l’attribut ModeleId. En plus il faudrait nécessairement un index supplémentaire (de type UNIQUE), ce qui représenterait un surcoût dont on se passerait franchement lors des opérations de mise à jour de la table. Bref, ajouter l’attribut ModeleMonoId étant non seulement inutile (noter au passage la bijection entre les ensembles {ModeleId} et {ModeleMonoId}), mais en plus néfaste, donc on s’abstiendra.

Table MODELE_MULTI

Mêmes remarques.

Table MODELE_MONO_CAR

Même genre de remarques. {ModeleMonoCarId} remplaçant la paire {ModeleMonoId, CaracteristiqueId} dans le rôle de clé primaire, toujours au nom de l’UNICITÉ, il n’en demeure pas moins que {ModeleMonoId, CaracteristiqueId} devrait impérativement faire l’objet d’une clé alternative, avec là encore mise en oeuvre d’un index supplémentaire, d’où surcoût en mise à jour.

Impact sur les performances :

Supposons que pour une valeur de l’attribut ModeleMonoId de la table MODELE_MONO_CAR vous ayez besoin de connaître le nom de la marque correspondante.

Avec le système de clés primaires que j’ai proposé, il suffira de procéder à la jointure des tables MODELE_MONO_CAR, MODELE et MARQUE.
Avec votre système, il faudra en plus faire participer la table MODELE_MONO : encore un surcoût dont on se passerait volontiers. Je vous invite à voir à ce propos l’exemple des livraisons (Dénormalisation vs amélioration (optimisation), 4e exemple, requêtes 1 et 4).

Table MODELE_COMPOSITION

En plus des remarques précédentes qui continuent à s’appliquer : avec le système de clés primaires que j’ai proposé, du fait de la clé primaire {ModeleId, TypeMaterielId, CaracteristiqueId} la contrainte d’unicité des triplets {modèle, type de matériel, caractéristique}, par exemple <DX2000MT, Disque dur, 250 GB> est respectée. Mais avec le nouveau système, l’attribut ModeleId disparaît et une clé alternative ne suffit plus pour pallier : il faut prévoir une assertion impliquant une jointure des tables MODELE_COMPOSITION et MODELE_MULTI pour contrôler les infractions. Encore un surcoût dont on préfèrerait se passer...

Bref, si l'on a en tête le principe du rasoir d'Ockham, on évitera les clés singletons systématiques...

Bonne octave de Noël.

**drakuncorp** · 26/12/2011, 09h33

okay , la je suis cool.
en attendant la suite et en fonction de votre disponibilité, je vous souhait un joyeux noel

Maj MODELE

En passant quand je charge ma config j'ai un message

**fsmrel** · 26/12/2011, 16h23

Bonjour Drake,

Merci pour vos voeux. Je vois que nous d'accord au sujet des clés singletons...

Rappel des assertions concernant les bons (si le SGBD ne connaît pas l’instruction CREATE ASSERTION, utiliser une instruction CREATE TRIGGER en procédant aux aménagements inhérents).

La liste ci-dessous ne prétend pas à l’exhaustivité, à vous de compléter si nécessaire...

Code SQL :

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
----------------------------------------------------------------------------------------------------
-- La succursale mentionnée par le bon d'entrée doit être celle du matériel.
-- Erreur si le bon d'entrée fait référence à une succursale qui n'est pas celle du matériel,
-- ou bien si le matériel n'est dans aucune succursale.
-----------------------------------------------------------------------------------------------------
CREATE ASSERTION Assert_Bons_01 CHECK
   (NOT EXISTS (
                SELECT 'Aïe ! '
                FROM
                    (
                     SELECT x.BonId, x.MaterielId, x.EntiteId, y.SuccursaleId
                     FROM   BON AS x JOIN MATERIEL_EN_SUCC AS y ON x.MaterielId = y.MaterielId
                     WHERE  x.BonType = 'entrée' AND x.EntiteId <> y.SuccursaleId
                     UNION
                     SELECT x.BonId, x.MaterielId, x.EntiteId, 0
                     FROM   BON AS x
                     WHERE  NOT EXISTS (SELECT ''
                                        FROM   MATERIEL_EN_SUCC AS y
                                        WHERE  x.MaterielId = y.MaterielId)
                     AND  x.BonType = 'entrée'
                    ) AS x
               ))
;

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
------------------------------------------------------------------------------------------------------
-- La succursale du valideur d'un bon d'entrée doit être la succursale mentionnée par le bon
------------------------------------------------------------------------------------------------------
CREATE ASSERTION Assert_Bons_02 CHECK
   (NOT EXISTS (
                SELECT 'Aïe ! ' 
                FROM   BON AS x JOIN ENTREE_VALIDATION_SUC AS y ON x.BonId = y.BonEntreeId
                                JOIN VALIDEUR_SUCC AS z ON y.ValideurSucId = z.ValideurSucId
                WHERE  x.BonType = 'entrée' AND x.EntiteId <> z.SuccursaleId
               ))
;

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
---------------------------------------------------------------------------------
-- Le valideur de la hotline ne doit valider directement que des bons de sortie
---------------------------------------------------------------------------------
CREATE ASSERTION Assert_Bons_03 CHECK
      (NOT EXISTS (
                   SELECT 'Aïe ! '
                   FROM   BON AS x JOIN  SORTIE_VALIDATION_HOT AS y ON x.BonId = y.BonSortieId
                   WHERE x.BonType <> 'sortie'  
                  ))
;

Code SQL :

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

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

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
----------------------------------------------------------------------------------------------------
-- Le matériel à destination d'une succursale ne doit pas arriver dans une autre succursale
----------------------------------------------------------------------------------------------------
 
CREATE ASSERTION Assert_Bons_05 CHECK
   (NOT EXISTS (
                SELECT 'Aïe ! '
                FROM   BON AS x JOIN SORTIE_VALIDATION_SUC AS y ON x.BonId = 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  
               ))
;

Question : quel est votre SGBD ?

**drakuncorp** · 26/12/2011, 16h47

Actuelement , j'utilise Mysql(les assertions n'y marchent pas) mais je pense à basculer sur oracle plu tard

**fsmrel** · 27/12/2011, 02h38

Bonsoir,

Les assertions seront donc à convertir en triggers, car l'instruction CREATE ASSERTION (conforme à la norme SQL) n'est pas proposée à ce jour, que ce soit par MySQL, Oracle et compagnie. Elle existait pourtant (dès 1976 ! et s'appelait alors ASSERT) dans SEQUEL 2 (aka SQL), langage du prototype SYSTEM R d'IBM (dont Oracle est du reste le fils illégitime...)

Bon courage...

**drakuncorp** · 27/12/2011, 09h26

Bonjour,
D'accord, je procéderai a la création des triggers et vous les présenterais plutard.

Ceci fait, la vue MODELE est terminée et valide (pour ma part il résoud parfaitement mon problème)

Alors El Maestro je suis à votre écoute pour la prochaine vue.

Merci et bonne journée à vous

**fsmrel** · 27/12/2011, 17h52

Bonsoir,

Je n’avais pas vu l’ajout que vous aviez effectué à votre message :

Il est évident que l’index fk_modeles_typemateriels_modeles1 doublonne avec l’index « primaire », il est parfaitement inutile et doit disparaître, il ne pourrait que concourir à un surcoût de consommation de ressources lors des opérations de mise à jour. Je rappelle à ce sujet le sage principe de parcimonie énoncé par Guillaume d’Ockham :

« Pluralitas non est ponenda sine necessitate » (autrement dit, ce qui ne sert à rien : poubelle !)

Envoyé par drakuncorp

je suis à votre écoute pour la prochaine vue

Which one ?

**drakuncorp** · 27/12/2011, 19h48

It is you master(teacher)

Mais comme vous me laissez le choix alors j'opte pour le circuit panne réparation et pièce intervenant dans la réparation.

et plutard faire une "maintenance" de tout ce tas de monde

yep, bonne soirée

**fsmrel** · 30/12/2011, 00h17

Bonsoir Drake,

Selon votre vue RÉPARATIONS, tous les tiers ont effectué (ou sont en train d’effectuer) des réparations : il y a de l’optionalité à mettre en place ! Même chose : toute réparation implique au moins une pièce : n’y a-t-il pas des situations dans lesquelles un tiers (ou peut-être vous-même) a pu réparer, en bougeant des fils, sans avoir à changer des pièces ?

D’après les exemples de valeurs que vous aviez fournis (boîtier d’alimentation, disque dur) pour la table PIECE (pieces dans votre vue), celle-ci correspond plutôt à une table de types de pièces. En conséquence, elle ferait double emploi avec ce dont on dispose déjà (table TYPE_MATERIEL), et comme disait Guillaume d'Ockham...

Pour quel motif précis avez-vous une relation 0,N entre PANNE et REPARATION ? S’agit-il pour une panne donnée de faire procéder à plusieurs réparations par le même tiers ? Et/ou faire intervenir successivement différents tiers pour cette panne ?

=> Il faudrait que vous racontiez l’histoire des pannes...

Je commence l’histoire. Par exemple, le petit ordinateur o123 (valeur de l’attribut Id de la table MATERIEL) tombe malade. Il passe à l’état (disons) « en panne » : à vous de continuer... Cherchez-vous à effectuer vous-même un diagnostic ? Ou envoyez-vous plutôt systématiquement o123 chez un tiers (disons M. Johnny, docteur des ordinateurs) qui effectuera lui-même le diagnostic ? Supposons que c’est le disque dur qui soit malade. Envoyez-vous o123 chez Johnny ? Seulement le disque ? Supposons que Johnny change le disque : vous suffit-il de savoir qu'il y a eu remplacement du disque dur ? Si les caractéristiques du nouveau disque ne sont pas les mêmes que celles de celui qui était malade (exemple, capacité du disque différente ou marque différente, etc.), a-t-on besoin de le savoir s'en fiche-t-on ?

Racontez l’histoire de l’écran Dell qui tombe en panne et qui est remplacé par un Samsung (ainsi que la carte graphique, par ce que l’originale ne convient pas...)

Etc. (à moins qu’il n’y ait pas d’histoire à raconter, un peu comme lorsque le cendrier de la voiture de Marie-Chantal est plein, on change la voiture...)

A propos des assertions :

Les assertions seront à convertir en triggers, car l'instruction CREATE ASSERTION (conforme à la norme SQL) n'est pas proposée à ce jour, que ce soit par MySQL, Oracle et compagnie. Elle existait pourtant (dès 1976 ! sous le nom : ASSERT) dans SEQUEL 2, l'ancêtre de SQL (langage du prototype SYSTEM R d'IBM).

**drakuncorp** · 30/12/2011, 09h44

Bonjour Fsmrel,

Vous avez parfaitement raison, il faut que je rapporte plus de clarté sur cette vue:
Tous les tiers ne sont pas en train d'effectué de réparations et toutes réparations peuvent ne pas impliquer de pièces.

Avec la mise MAJ que vous avez faites sur la vue MODELE type de matériel correspond à type de pièces.

La relation entre panne et réparation (une réparation n'est faites que par l'existence d'une panne)

Un peu d'history ....

matériel O123 tombe en panne,
je cherche à faire un diagnostic, deux cas de figure :
Fig 1: j'arrive à remèttre en état.
Si une pièce est défectueuse ex DISK DUR, Carte Graphique ou Boitier d'alimentation, je passe commande et dès réceptions de la pièce, je procède au montage.
Fig 2: J'y arrive car je suis nul, donc j'expédie le matériel chez Johny(le materiel au complet). Johny fait le diagnostique et répare sil le peut.Des pièces peuvent intervenir ou pas dans son processus.

NB: Une bonne remarque de votre par : exemple, capacité du disque différente ou marque différente, etc.), a-t-on besoin de le savoir s'en fiche-t-on ? ne serait il pas mieux de le savoir car franchement je n'avais pas cette vision.

Un écran DELL tombe en panne , s'il est hors service ( c'est à dire de retour de chez le tiers " johny n'étant pas en forme ce jour là") l'état est hors service. en attendant une décision de la hierarchie pour le mettre au rebus etat final "REBUS"

deux cas de figure aussi
1---> Remplacer par un autre (ex Samsung) en stock ou récupéré quelques par dans le parc.
2---> Passer une commande (commande de lot Hah comme disait Guillaume d'Ockham... )

Voici la brève histoire de cette vue. elle sera plus détaillée par la suite en fonction de vos Schéma si clair qui met de l'ordre dans nos têtes.

Une question: pourrait on faire une assez simple gestion du budget des réparations (c'est à dire savoir le coût d'une réparation pour faire des cumuls sur des périodes ou par exemple le total des dépenses annuelles dédiés à la réparation)

y-a t-il des changements à faire sur mon modèle si je voudrai faire des statistiques plu tard vu que qu'ils ont une grande importance pour le décisionnel.

Si j'arrive à vous relire avant le nouvel an tant mieux sinan BONNE ET HEUREUSE année 2012 anticipés à vous et tous vos proches.
MERCI ENCORE FSMREL

**drakuncorp** · 02/01/2012, 10h08

Bonjour,

Une remarque que j'ai fait sur votre schéma MODELE
les tables MODELE_MONO_CAR et TYPE_MAT_CAR ne font elle pas la meme chose.
Guillaume d’Ockham :
« Pluralitas non est ponenda sine necessitate » (autrement dit, ce qui ne sert à rien : poubelle !)

Nespa ???

Bonne journée

gestion parc informatique [MCD]

Schéma

Discussions similaires

Partager

Partager