Discussion :

[info3licen]

Bonsoir

Je voudrais réaliser une application qui permet de faire la gestion de stock, un stock informatique, mais la je suis bloqué sur le mcd, le stock comporte du équipement informatique l'équipement est devisé en deux du "matériel" et du "consommable" la je sais pas quoi faire. Est-ce que je peux faire une entité équipement qui généralise deux entité matériel et consommable c'est à dire je fais entré la notion de l'héritage ou y a t-il une autre idée ?

Merci pour votre attention

[ego]

yes pour l'héritage

[Richard_35]

Bonjour Info3licen et Ego,

Ego.

Détail :

Code :

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

1
2
3
Produit -1,1---[Être]---0,1- Materiel
   |
   +-----1,1---[Être]---0,1- Consommable

donnant :

Produit(IdProduit, Libelle, [informations communes aux matériels et aux consommables]) ;
Materiel(#IdProduit, [informations propres aux matériels]) ;
Consommable(#IdProduit, [informations propres aux consommables]).

contraintes :

• un produit doit être, obligatoirement, un matériel OU un consommable ;
• un produit ne doit pas être un matériel ET un consommable.

[ok.Idriss]

Bonjour.

Dans le cas échéant, il s'agirait d'utiliser un héritage par partition (totalité et exclusion XT) entre l'entité mère Produit et les entités filles Matériel et Consommable.

Vous trouverez un exemple détaillé ici ainsi que différentes implémentations possibles au niveau relationnelle. Vous pouvez également consulter la FAQ à ce sujet.

@Richard_35 : l'implantation au niveau relationnel et les contraintes énoncées correspondent bien à un héritage par partition mais votre modélisation conceptuelle avec une association "être" peut porter à confusion, même si le lien sémantique correspond. Notamment avec la cardinalité 1,1 du côté de l'entité mère

Pourquoi ne pas représenter l'héritage en Merise II directement (avec le symbole XT qui symbolise les contraintes que vous avez énoncé) ?

Cordialement,
Idriss

[wiztricks]

Salut,

Est-ce que je peux faire une entité équipement qui généralise deux entité matériel et consommable c'est à dire je fais entré la notion de l'héritage ou y a t-il une autre idée ?

C'est vous qui faites la conception, donc vous pouvez faire ce que vous voulez et opter pour:

- garder ces entités séparées,
- créer une superclasse "Produit" dont hériteront Matériel et Consommable,
- décréter que Matériel est une s/classe de Consommable,
- ne pas différencier Matériel et Consommable: il y a (ou pas) des articles en stock,

Quel que soit le choix, pas de "problème" pour le réaliser techniquement...

Quelle sera la moins mauvaise option? Vous donnez trop peu d'information pour "choisir".

Cordialement,
- W

[info3licen]

Merci pour vos réponse

Avec l'héritage je me suis retrouvé encore bloqué
je donne un exemple si j'ai un produit "Imprimante" dans le stocke j'aurais plusieurs imprimante avec un numéro de série différent, alors lors du passage au modèle relationnel ça me pose un certain problème puisque si je donne par exemple pour le produit "imprimante" n= 01 si je vais faire entrée dans ma table "Matériel' toutes les imprimantes existante dans le stock ça ne marchera pas puisque la clé primaire dans la table matériel est celle de la table produit

-J'ai essaie de faire une seule classe qui regroupe le matériel et le consommable => ça me pose aussi un problème puisque le matériel possède un et un seul numéro de série donc c'est la clé primaire mais le consommable n'as pas de numéro de série alors ils ne peuvent pas être dans la même classe

-et j'ai essaie de faire deux classe une pour consommable et l'autre pour matériel mais puisque les deux produit vont être affecté a des service et sont acheté par des fournisseur alors la je me trouve avec des table en double par exemple (écran est affecté a service A et cartouche est affecté a service A) donc la j'aurais deux tables dans ma base est_affecter1 et est_affecter2

je sais pas quoi faire si vous pouvais me donné une petite orientation je serais très reconnaissante
Merci

[ok.Idriss]

Re bonsoir.

De manière générale, il existe différents types d'héritages comme il existe différentes implémentations relationnelles (cf : le lien que je vous ai fournit dans mon précédant message).

Si vous choisissez l'implémentation précédante :

Code :

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

1
2
Produit(IdProduit, Libelle, [informations communes aux matériels et aux consommables]) 
Materiel(IdProduit#, [informations propres aux matériels])Consommable(IdProduit#, [informations propres aux consommables])

Une occurrence de la relation Materiel devra se trouver dans la relation mère produit. Ce modèle est le plus générique auquel on peux appliquer toutes les contraintes : totalité, exclusion et partition. Avec un héritage par totalité rien n'empêche qu'un produit soit à la fois Materiel et Consommable, le problème de contrainte d'unicité des occurrences ne se pose qu'au sein d'une relation. Rien n'empêche d'avoir l'occurence suivante :

Code :

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

1
2
3
Produit : 1 | imprimante epson 395+
Materiel : 1 |  ...
Consommable : 1 | ...

Après je ne suis pas sûr d'avoir saisi votre problème. Ensuite lorsqu'une donnée est unique et doit faire l'objet d'une contrainte d'unicité au sein d'une relation, il n'est pas obligatoire d'en faire l'identifiant de la relation. Un numéro entier identifiant dans la relation mère, et un numéro de série qui fera l'objet d'une contrainte d'unicité (UNIQUE en SQL) dans la relation fille.

Enfin, ne raisonnons pas en terme de classe lorsqu'il s'agit de modélisation de base de données relationnelles

Cordialement,
Idriss

[Richard_35]

Bonjour à tous,

@Richard_35 : l'implantation au niveau relationnel et les contraintes énoncées correspondent bien à un héritage par partition mais votre modélisation conceptuelle avec une association "être" peut porter à confusion, même si le lien sémantique correspond. Notamment avec la cardinalité 1,1 du côté de l'entité mère

==> désolé, Ok.Idriss, je ne comprends pas la remarque en gras.

Pourquoi ne pas représenter l'héritage en Merise II directement (avec le symbole XT qui symbolise les contraintes que vous avez énoncé) ?

==> oui, c'est exact, mais je n'ai pas l'outil graphique nécessaire.

Enfin, ne raisonnons pas en terme de classe lorsqu'il s'agit de modélisation de base de données relationnelles

==> tout est là !

je donne un exemple si j'ai un produit "Imprimante" dans le stocke j'aurais plusieurs imprimante avec un numéro de série différent

==> effectivement... mais, si tu donnes les informations fondamentales au compte-goutte, cela va être difficile de t'aider .

Info3licen, tous les matériels (Materiel) comporteront-ils des n° de série à gérer ?

[info3licen]

Merci encore une fois et désolé de ne pas avoir été trop claire !

j'essaie d'expliquer :

1-Le stocke comporte équipement informatique, l'équipement peut être soit matériel soit consommable, le matériel possède un numéro de série (peut être comme clé) par contre le consommable n'as pas de numéro de série

2-tout L'équipement informatique est acheté à partir d'un fournisseur.

3-l'équipement informatique est affecter a des service.

Moi je bloque en (1)...

je donne un exemple :

Equipement Info : (n=01, Ecran,...)
(n=02, imprimante,...)
(n=03, unité,...)

Matériel : : (n=01#,ecran_Dell, n_ser...)
(n=01#, ecran_Hp, n_ser...) ==>et la j'aurais le problème de violence de la clé primaire !!!


PS: Oui tout le matériel possède un numéro de série que je ne dois pas négliger

[Richard_35]

Vite fait, peut-être :

Code :

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

1
2
3
4
5
Produit -1,1---[Être]---0,1- Materiel
   |                            |
   |                        (XT)/(+)
   |                            |
   +-----1,1---[Être]---0,1- Consommable

donnant :

Produit(IdProduit, Libelle, QuantiteStock, [informations communes aux matériels et aux consommables]) ;
Materiel(#IdProduit, NumeroSerie, [autres informations propres aux matériels]) ==> index unique sur NumeroSerie (non null) ;
Consommable(#IdProduit, [informations propres aux consommables]).

Contraintes :

• un produit doit être, obligatoirement, un matériel OU un consommable (+) ;
• un produit ne doit pas être un matériel ET un consommable (XT) ;
• un produit "Materiel" doit avoir une QuantiteStock=0 ou =1.

[ok.Idriss]

Bonjour.

Equipement Info : (n=01, Ecran,...)
(n=02, imprimante,...)
(n=03, unité,...)

Matériel : : (n=01#,ecran_Dell, n_ser...)
(n=01#, ecran_Hp, n_ser...) ==>et la j'aurais le problème de violence de la clé primaire !!!

Vous confondez le type d'un équipement et l'équipement lui-même qui est la généralisation d'une (et une seule) occurrence d'une des relations filles. L'identifiant du type d'équipement ne doit pas participer dans l'identifiant de la relation Materiel, sinon vous avez bien une violation de contrainte d'intégrité référentielle comme c'est le cas dans votre exemple.

Votre modélisation est donc trop confuse, il faut reposer les choses à plat. Commençons par le lien sémantique entre un type d'équipement et un matériel :

Code :

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

TypeEquipement (id, libelle) --0,N-- (Correspondre_t_m) -- 1,1 -- Materiel (id, designation, etc)

Avec ce modèle on peux bien avoir les occurrences que vous avez décrites à savoir :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
TypeEquipement :
id, libelle
1, UC
2, Écran
3, imprimante
...

Materiel :
id, designation, idType#
1, écran dell 15 pouces, 2 (=> Écran)
2, HP-DV6, 1 (=> UC)
3, écran HP 17 pouces, 2
...

Si toutefois un consommable correspond à un type d'équipement mais que ce dernier ne peut correspondre qu'à des matériels ou des consommables, vous pouvez ajouter le lien sémantique suivant dans votre modèle, en veillant à rajouter une contrainte d'exclusion avec l'association précédente.

Code :

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

TypeEquipement (id, libelle) --0,N-- (Correspondre_t_c) -- 1,1 -- Consommable (id, etc)

Pour les contraintes inter-associations : ineumann.developpez.com/tutoriels/merise/initiation-merise/#LIV-C (voir la contrainte d'exclusion en particulier).

Enfin si des propriétés sont communes aux consommables et matériels, vous pouvez faire une généralisation avec un héritage par partition mais en ne confondant pas le type et l'équipement en lui même :

Code :

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

1
2
3
4
TypeEquipement (idType, libelle)
Equipement (id, designation, idType#)
Materiel (id#, num_serie UNIQUE et NOT NULL, etc)
Consommable (id#, etc)

Il s'agira au niveau conceptuel d'un héritage par partition entre Equipement Materiel et Consommable (cf : http://ineumann.developpez.com/tutor...-merise/#LIV-C ).

Les contraintes inter-associations et la contrainte de partition devront être satisfaites à l'aide de traitements (les triggers sont bien adaptés pour ce genre de choses).

Bien voilà, je ne suis pas sûr que cela réponde à vos attentes mais c'est un modèle un ne peu plus claire déjà

Si ça ne répond pas à vos attentes, posez d'avantages vos besoins à plats avant même de définir vos règles de gestion, par exemple en nous donnant des exemples de consommables (je ne vois toujours pas ce que c'est avec précision, etc).

Cordialement,
Idriss

[info3licen]

Merci beaucoup idriss, je commence a voir bien les chose maintenant

j'opte pour votre première réponse, puisque maintenant j'ai remarqué qu'il n'y a pas d'information commune entre le matériel et le consommable alors j'ai pas besoin d'avoir une classe mère, donc j'aurais :

Type_equi(id, lib)

Materiel(Num_ser, designation, id_type#)

Consommable(id_con, designation, id_type#)

J'espère que je suis sur la bonne voie!

Merci

[ok.Idriss]

Re - bonsoir.

Oui c'est en meilleure voie. Maintenant, rien ne vous empêche en plus de faire un héritage (comme dit dans mon précédant message) :

Code :

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

1
2
3
4
Type_equi(id_type, lib)
Equipement (id, designation, id_type#)
Materiel(id#, Num_ser {UNIQUE, NOT NULL})
Consommable(id#)

Encore une fois une donnée qui fait l'objet d'une contrainte d'unicité ne doit pas forcement faire l'objet d'une clef.

Là vous retrouvez bien votre modèle précédant avec en plus une généralisation.

Cordialement,
Idriss

[info3licen]

Mille merci Idriss

Je vais travailler avec votre solution si j'aurais d'autre problème je reviendrais

Merci beaucoup vous m'avez vraiment aider