Discussion :

[jogodepau]

Bonjour,

je vous remercie d'avance pour prendre le temps de me lire.

J'ai effectué deux MCD, ci-joint et je voudrais avoir votre avis lequel est juste).

Mon projet et de gérer les stock et les opérations sur ses derniers

1- on a un stock balise
le stock balise est divisé en plusieurs stock on a stock disponible, stock occupée, stock perte, stock SAV.

2- un stock sim (puce), on a stock disponible, stock occupée, stock quarantaine (dure 2 mois),stock SAV, stock perte.

3- un stock antennes, on a stock disponible, stock occupée et stock SAV.

- La balise à un type, chaque type comporte 2 ou 3 paramètres.
- La sim (puce) à un type également.


on dispose d'une liste de client qui ont acheté des balises.
chaque client à un compte.
chaque client peux avoir ou pas un service.
chaque service à un sous service.
chaque service et sous service à un compte également.
le client a un ou plusieurs véhicules qui sont dispatcher entre les services.


Les véhicules de chaque sous service son visible depuis son compte mais aussi du compte de son service...

Si au moment d'avoir un lot de véhicules (appartenant à un client) et qu'on dispose pas encore de leurs immatriculation on leurs affectent un id_provisoir.

la balise quand elle est en stock disponible, elle n'est reliée ni à une puce ni à une antenne, si par contre on la place sur le véhicule d'un client, on lui affecte une sim, une antenne et un ID_DW (identifiant pour la reconnaitre sur la plate forme)

le fait de placer la balise sur un véhicule nécessite une opération d'installation, ils peux y avoir d'autre opérations qui nécessite le changement d'une puce seulement ou d'une antenne ou d'une balise ou on peux avoir à permuter une balise sur un autre véhicule...tout ceci est effectué par un technicien.
donc on peux voir une sim qui était sur une balise être affectée à une autre et c'et le cas aussi pour les balise c'est pour cela qu'on a besoin d'un historique.

Merci beaucoup.

J'espère que j'étais clair dans mon explication.

merci de me donner vos avis pour pouvoir passer à l'étape suivante.

Bonne journée à vous et merci encore.

[jogodepau]

bonjour,
svp j'ai vraiment besoin de votre avis pour mes MCD, lequel est correct pa rapport à mon explication,
merci encore.
bonne journé

[gototog]

Tu as des problemes avec les triassociations je pense, une association avec des cardinalitées 1.1, 1.1, 0.n, c'est une erreur.

Tu as inversé les cardinalités service - Clients, on lit un service n'a qu'un seul client actuelement dans tes deux schemas

chaque client à un compte.
chaque client peux avoir ou pas un service.
chaque service à un sous service.
chaque service et sous service à un compte également.

Question basique, tu entends quoi par compte? un petit peu de contexte nous aiderai un peu je pense ^^ c'est un compte financier, un compte d'accès a l'application ...etc

de mon point de vue, l'id_provisoire n'est pas une entité, c'est une propriété qui peut ou ne peut pas etre renseigné, de meme pour les antennes.

Faire une entité calendrier ave cun ID date j'ai toujours trouvé ca bizarre meme si c'est aprécié des professeurs , on va pas remplir une entité avec tous les jours du monde, autant laisser date en identifiant de l'association (en souligné dans l'association)


tu fais également des asssociation fausse: une association 1,1 ---- blabla--- o,n ne peut PAS contenir de propriété!!!!

[jogodepau]

Bonjour,

merci pour ta réponse
je suis actuellement entrain de tout refaire, excuse ma bêtise cela fait un bail que j'ai pas mis la main à la pate!



Tu as inversé les cardinalités service - Clients, on lit un service n'a qu'un seul client actuelement dans tes deux schemas
si je comprend bien, client 0,n-----------1,n service
même chose pour service 0,n------------1,n sous-service


Question basique, tu entends quoi par compte? un petit peu de contexte


Le compte représente un compte d'accès à une application existante sur le nt depuis laquel chaque client , service ou sous service peu visualiser ses véhicules qui sont équipés de balise.

de mon point de vue, l'id_provisoire n'est pas une entité, c'est une propriété qui peut ou ne peut pas etre renseigné, de meme pour les antennes.

pourquoi pour les antennes, car on a un stock d'antennes chaque une va être affectée à une balise donc elle aura un historique..

merci encore pour ta réponse.

[jogodepau]

Re:

Je viens de refaire un MCD, hellllllllllp please, je ne sais plus

merci de me donner votre avis.

[gototog]

Bon, je te propose de le refaire petits bouts par petits bouts.. (ca devient un peu le bowdel ton MCD, il y'a des entités non liées ^_^)


Commençons par balise et type balise.

Sur ton dernier schéma tu as mis balise--0.1---Concerner---0.n----Type Balise

Il y'a des balises sans type?
Si oui, c'est juste, si non, c'est une association 1.1 --Concerner--- 0.n


Passons par le stock de balise.

ce que tu as modélisé est faux, cf mon ancien message. une association 1.1---0.n n'a jamais de propriété "a l'interieur".

Personnelement, pour modeliser les opérations de stock je me fait une entité de ce style:
Opération_Stock
id_opérationStock
sens_operationStock (qui contiendra entré/sorti ou dépot/retrait etc..)
date_opérationStock

essaye de modeliser juste ces petits bouts

[jogodepau]

Bonjour,

ok:

Les balises ont un type dès le début, une balise peu avoir qu'un seul type mais on peu avoir plusieurs balises d'un même type (chaque type a deux ou trois paramètres?).


On ce qui concerne le stock de balises, on faite:
1- Dès réception des balises ils entrent dans un stock appelé stock disponible.
2- Dès que les balises sont achetées par un client, rentrent dans le stock indisponible.
3-Dès qu'une balise a un problème elle entre dans le stock SAV sinon si ce n'est pas le cas et qu'elle est out elle rentre dans le stock perte

Donc pour cela j'ai imaginé une table stock-balises où on va énumérer tout les type de stock; une balise ne peut être que dans un stock à la fois.

Je vais dessiner la R/E pour ces deux et j'avance ainsi!

Je te remercie pour ton aide et ta patience.

[gototog]

Pour tes identifiants, il est vrais que les noms de tes types ou les noms de tes stocks sont uniques. néanmoins, je t'encourage a utiliser des identifiants numériques, afin de prévenir tout changement de nom, fautes d'orthographe...

[par exemple un nouveau chargé des stocks un peu écolo arrive et veut que le stock perte soit renommer stock recyclage ]


petit soucis dans ta modélisation de stock balise:
je vais remplir ta futur base de données, et je pense que tu vas te rendre compte de l'erreur :
stock_balises
Pertes, dépot, 01/01/2011
Disponible, retrait, 05/06/2011
Indisponible, dépot, 04/07/2011

que ce passe t'il si tu déposes une nouvelle pièce dans le stock pertes? ca écrase l'ancienne donnée.

Donc nous avons bien une entité stock_balises qui prend le nom des différents stocks
stock_balises
ID, nom_stockBalise

Par contre, il te faut soit une association ternaire, soit une entité (en modélisation pur et dur, l'association est plus juste, en optimisation de traitement et facilité de développement, l'entité est plus agréable, je ne sais pas ce qu'en penses les autres membres)

Avec une association:

Réflechissons, qu'est ce qui différencie une opération de stock d'une autre: sa date, sa balise et son stock
Nous avons donc trouvé les trois identifiants de l'association,
Etre stocké
id_balise, id_stock, date_heure
et en propriété toutes ses autres informations


Avec une entité (elle sera lié par des liens 1.1----0.n a balise ainsi que stock)
Opération Stock
id_operation,
date_opération
et toutes ses autres informations

A toi de choisir ce que tu préfères!

[jogodepau]

Si j'ai bien compris cela va ressembler à ceci.

Seulement je t'explique, comme c'est un MCD l'association portera que la date car le reste elle le récupérera des autres entités.

Mon MCD est comme joint et mon MLDR est comme suit:


type_balise (nom_type) stock_balises (id_stock_balise, nom_stock_balise) balises (id_balise, num_balise, imsi_balise, #nom_type) opération_stock (id_opération_stock_balise, date_opération) être_stocké (id_stock_balise, id_balise, id_opération_stock_balise, date_stock)


Seulement je ne comprend pas pourquoi l'association être stocké a une date et l'entité opération stock à une date (ce n'est pas une redondance?)
ou j'ai pas pigé un truc?
merci

[gototog]

Je me suis surement mal exprimé, je voulais te proposer soit d'utiliser une association, soit une entité, mais pas les deux en meme temps.

(ducoup la date est bien redondante en utilisant les deux.)

[jogodepau]

ok, j'ai compris.
je voulais te poser une autre question: Les valeurs des identifiants que je dois donner à chaque clé d'entité doivent être choisies comment? en lettre, chiffres ou des nom représentatif
exemple id_ stock_balise occupé 11 ou A ou occ (pour ocupper)?

qu'es ce que tu pense de cette partie de l'MCD que j'ai refais par ton aide?
j'ai pas fini!
merci encore

[gototog]

Pour tes identifiants, il est vrais que les noms de tes types ou les noms de tes stocks sont uniques. néanmoins, je t'encourage a utiliser des identifiants numériques, afin de prévenir tout changement de nom, fautes d'orthographe...
[par exemple un nouveau chargé des stocks un peu écolo arrive et veut que le stock perte soit renommer stock recyclage ]

j'utilise tous le temps des identifiants numériques, car ils ne seront jamais changé quoi qu'il arrive. j'ai une approche orienté programmation dans mon analyse.


Pour l'association, c'est une ternaire (0.n/0.n/0.n) entre
Balise, stock, et date.

Date est une entité que je ne modélise jamais personnellement, car je trouve ca idiot de modéliser cette entité qui complexifie le schéma tout en étant inutile.

Ton 1.1 me gène:
Prenons ton cas de service après vente:
ta balise passe en stock SAV, ils la répare, la redonne au client, et quelques mois plus tard, le client la ramène en SAV.
Elle est donc allé plusieurs fois dans un stock, c'est du 1.n!



Pour les SIM, je te repose ma question sur les balises :p

Commençons par balise et type balise.

Sur ton dernier schéma tu as mis balise--0.1---Concerner---0.n----Type Balise

Il y'a des balises sans type?
Si oui, c'est juste, si non, c'est une association 1.1 --Concerner--- 0.n

Et pour finir, qu'est ce qui empeche un client d'acheter une SIM et aucune balise? ou l'inverse? ou deux de chaque?
tu a mis une association ternaire bizarre, sauf si un client achete TOUJOURS une sim avec une balise, tu peux mettre client---0.n---Achete----0.n-SIM et une autre association client---0.n---Achete----0.n-Balise

[jogodepau]

Ok pour le identifiants.


Pour l'association, De quelle association parle-tu? balise_stocké ou acheter, car je ne voie pas de date sauf dans les associations)
sinon tu préfère que je mette la date dans l'entité stock_balises?

Ton 1.1 me gène:
Prenons ton cas de service après vente:
ta balise passe en stock SAV, ils la répare, la redonne au client, et quelques mois plus tard, le client la ramène en SAV.
Elle est donc allé plusieurs fois dans un stock, c'est du 1.n!

On faite ma logique étant que pour moi il y a plusieurs tables de stock, une balise ou une sim ne peut être que dans une seul table et pas dans toutes les tables en même temps(càd: si j'ai stock sav, et stock occupée, dispo la puce si elle est dans sav ne peut être dans disponible ni dans occupé, même chose pour la balise) , je me trompe en raisonnant comme ceci?

Pour les SIM, je te repose ma question sur les balises :p


Et pour finir, qu'est ce qui empeche un client d'acheter une SIM et aucune balise? ou l'inverse? ou deux de chaque?
tu a mis une association ternaire bizarre, sauf si un client achete TOUJOURS une sim avec une balise, tu peux mettre client---0.n---Achete----0.n-SIM et une autre association client---0.n---Achete----0.n-Balise

en faite le client au début achète tjrs un lot: balise sim et antennes mais après cela il peut bien acheter une balise seul, une sim ou une antenne en cas de panne de perte...

[jogodepau]

En ce qui concerne la date dans l'association, je ne voie pas le problème si cette dernière deviendra une table par la suite?
merci de m'en dire plus.


J'ai effectuer des petit morceaux séparés pour après les relier, merci de me donner votre avis encore une fois.
1- partie concernant les sim:
au début toutes les sim n'ont pas de type, ce dernier on l'affecte à une sim au moment de la mettre sur la balise càd après que le client l'ai acheté et qu'il demande qu'elle soit de type, roaming, gps ou autre.

2-partie balise la balise a un type dès le début, j'ai préféré le traiter seul car chaque type a des paramètre spécifique paramètre 1, paramètre 2.

EN ce qui concerne les stock c'est vrai qu'une balise peu rentrer à plusieurs reprise en sav mais si elle est en sav elle ne peu être en dispo ni occupé(mise sur véhicule client), si elle est dispo elle ne peut être ni occupé ni sav ni ailleurs
mais il peut y avoir qu'elle soit dispo puis rentrer en stock occupé et puis revenir en stock dispo.

3-Le client peu avoir ou non des services ces deriers peuvent ou non avoir des sous servics, les véhicules qui appartiennent au client et sur lesquels on va placer le triplet sim et antenne qui vont sur la balise (c'est cette dernière qui va être placez sur le véhicule) ,
Dès l'achat de balise le client dispose d'un compte ainsi que chaque service ou sous service
Le compte du client permet de voir toutes sa flottes ainsi que celles de ses services et sous services sur un site web, le compte d'un service ne peux voir que les véhicules de ce service et également de son sous service, et pareil pour le sous service.

j'espère que j'étais clair en attendant que je raccorde les trois parties merci de me donner tes commentaires.

[gototog]

c'est plutot pas mal, ca avance

Les dates dans l'association:
Si tu met la date comme tel, c'est a dire comme simple propriété, ta table balise-stocké ne pourra pas avoir ce genre d'information:

balise1, stockSav, 04/04/2011 12:45:00, entré
balise1, stockSav, 04/05/2011 18:00:00, sortie

car ces deux informations ont le meme identifiant (ici balise1, stockSav,) donc la base de donnée va effacer le premier pour le deuxieme.

En passant la date en identifiant, ca regle le probleme:
balise1, stockSav, 04/04/2011 12:45:00, entré
balise1, stockSav, 04/05/2011 18:00:00, sortie
les deux données sont donc bien différentes

En résumé: le + c'est l'historique.


Concretement, dans ton dernier shema, il suffit de souligner la date.


Comptes et client:

Un véhicule n'appartient qu'a un seul client.
Un compte ne concerne qu'un seul véhicule
Un Sous service ne dépend qu'a un seul service.


Nous avons pour ton shema une simplification a effectuer.

En effet, si nous connaissons le véhicule, nous connaissons forcément le client, puisque un véhicule n'appartient qu'a un seul client!


J'ai une question, afin de peut etre simplifier Service/sous services:
Est ce que si nous avons un service composé de plusieurs sous service, le compte peut etre lié au service?

Concrètement, si nous avons:

Service Mettre_en_place
------Sous-Service Livrer
------Sous-Service Assembler
Service Comptabilité

Le compte peut être lié a Mettre_en_place/Livrer/Assembler/Comptabilité
ou seulement a Livrer/Assembler/Comptabilité ?


Et dernier question, est ce que le compte peut etre lié a plusieurs services sous service, par exemple, lié a Comptabilité et Livrer en meme temps?

J'ai pris des exemples un peu hors sujet, désolé ^^

[jogodepau]

Re:

En passant la date en identifiant, ca regle le probleme:
balise1, stockSav, 04/04/2011 12:45:00, entré
balise1, stockSav, 04/05/2011 18:00:00, sortie
les deux données sont donc bien différentes

Concretement, dans ton dernier shema, il suffit de souligner la date.

un identifiant = clé? Je ne savais pas que dans une association on peut mettre une propriété comme clé; le logiciel avec lequel j'effectue le mcd est AnalyseSI est ne me permet pas de souligné la propriété de l'association
balise_stocké, donc es ce que le fait de mettre la date dans la table balise_stock comme clé réglera le problème?

Comptes et client:

Un véhicule n'appartient qu'a un seul client.
Un compte ne concerne qu'un seul véhicule
Un Sous service ne dépend qu'a un seul service.

Oui, un véhicule n'appartient qu'à un seul client c'est sûr

Non, un compte d'un client concerne plusieurs véhicules (de ce client et pas d'un autre)

Oui, un sous service ne dépend que d'un seul service mais le service en lui même peut avoir plusieurs sous-services

J'ai une question, afin de peut etre simplifier Service/sous services:
Est ce que si nous avons un service composé de plusieurs sous service, le compte peut etre lié au service?

Concrètement, si nous avons:

Service Mettre_en_place
------Sous-Service Livrer
------Sous-Service Assembler
Service Comptabilité

Le compte peut être lié a Mettre_en_place/Livrer/Assembler/Comptabilité
ou seulement a Livrer/Assembler/Comptabilité ?


Et dernier question, est ce que le compte peut etre lié a plusieurs services sous service, par exemple, lié a Comptabilité et Livrer en meme temps?

J'ai pris des exemples un peu hors sujet, désolé ^^

Je vais essayer de reprendre ton exemple pour que tu arrive a saisir, si moi même j'ai bien saisie ce que tu veux dire

si nous avons:l Le client IBM
avec le
Service Mettre_en_place
------Sous-Service Livrer
------Sous-Service Assembler
Service Comptabilité

1- Le sous-service Livrer va avoir un compte livrer depuis lequel il va en se connectant voir tout les véhicules appartenant au sous-service Livrer

2- Le sous-service Assembler va avoir un compte Assembler depuis lequel il va en se connectant voir tout les véhicules appartenant au sous-service Assembler

3-Le service Mettre_en_place va avoir un compte Mettre_en_place depuis lequel il va en se connectant voir tout les véhicules appartenant au service Mettre_en_place ainsi q'au deux sous-services Livrer et Assembler.

4-Le client IBM va avoir un compte IBM depuis lequel il va en se connectant voir tout les véhicules appartenant à IBM càd les véhicules n'appartenant à aucun service ni sous-service et tout ceux qui appartiennent au service Mettre_en_place et aux sous-services Livrer et Assembler.

j'espère que c'est bien détaillé( c'est une arborescence)
et donc je voudrais faire apparaître pour chaque véhicule dans ma base le chemin du compte auquel il appartient càd si j'ai un véhicule X du sous service Assembler j'aurais dans mon tableau nom véhicule: X....chemin du compte: IBM\Mettre_en_place\Assembler.

Si je veux accéder au véhicule Y appartenant au service comptabilité je vais avoir nom véhicule: Y compte: comptabilité chemin du compte: IBM\comptabilité

Voilà
merci encore pour tes réponses cela m'encourage.

[gototog]

Non, un compte d'un client concerne plusieurs véhicules (de ce client et pas d'un autre)

Donc, un compte ne concerne qu'un seul client!

On commence a établir des règles de gestion plus solide déjà.


Alors, revenons sur la date. [oui, identifiant = clef]
Oui, effectivement, c'est pas dans la norme de mettre un identifiant dans une association.
Je développe: normalement, notre association serai lié aux trois entités Date, Balise et Stock.
Le probleme c'est que quand on modélise une entité aussi utilisé que date, ca va vite etre le bordel dans ton mcd si tu commences à la lier a toutes tes associations qui l'utilise.
C'est un peu une limite pratique/théorie.
Mais c'est juste de le modéliser en date, surtout si tu n'as pas le choix avec ce logiciel.



Pour service et sous service, merci d'avoir réutiliser mon exemple, j'ai compris je pense.

il y'a une possibilité de simplification je pense, qui s'oriente plus coté developpement que Modélisation, j'espère qu'un barbu intégriste du MCD ne passera pas par la.
Si nous modélison ce lien hierarchique comme ceci:
Service---0.n------------1.1-----Sous Service
c'est juste et sexy.

On a encore ce soucis d'avoir cette association :
id_Service,id_SousService, compte, id_client

C'est un peu comme si on avait idPapa,idEnfant : quand on connait l'enfant on connait le père, donc l'idPapa est inutile (ouai sauf orphelin mais le probleme est pas la)


Donc c'est assez contraignant de devoir lier Compte a SousService ET a Service.
Pour simplifier ce coté, on peut prévoir de mettre dans sous Service Le nom du service, en considérant qu'il englobe tout. Je m'explique:

Service Mettre_en_place
------Sous-Service Livrer
------Sous-Service Assembler
Service Comptabilité

Deviendrai: (avec un petit booleen isService, pour faciliter notre developpement)

Service Mettre_en_place
------Sous-Service Mettre_en_place , isService: 1
------Sous-Service Livrer , isService: 0
------Sous-Service Assembler , isService: 0
Service Comptabilité , isService: 1
------Sous-Service Comptabilité , isService: 0


Et la, on a une modélisation simplifié qui nous donne:
Service---0.n------------1.1-----Sous Service
Sous Service ---0.n-----------0.n---Compte

Service a disparu de cette association!

[jogodepau]

Le probleme c'est que quand on modélise une entité aussi utilisé que date, ca va vite etre le bordel dans ton mcd si tu commences à la lier a toutes tes associations qui l'utilise.

Et si je relier mon association à un calendrier plutôt! comme sur le dessin; ça fait vite bordel visuellement mais dans la pratique que je n'ai pas (je suis tombée sur ce liens http://merise.developpez.com/faq/?page=MCD
section: Comment modéliser les notions de temps (date, heure) ?

On a encore ce soucis d'avoir cette association :
id_Service,id_SousService, compte, id_client

C'est un peu comme si on avait idPapa,idEnfant : quand on connait l'enfant on connait le père, donc l'idPapa est inutile (ouai sauf orphelin mais le probleme est pas la)

J'avais devinée que la relation entre service et sous service était réflexive mais j'avais pas sus la représenter.
Dans ce cas qu'es ce qu'on fait de la relation véhicule compte et véhicule client et client compte?
Voici la modification que j'ai faite,

Merci de me donner ton avis encore une fois, tu est très de ta part

[gototog]

tu as client et voiture dans l'association, alors que quand on a la voiture on sait qui est le client.
Il faut en enlevé un, je te laisse voir lequel


Les relations ternaires sont plutôt rares enfait.

[CinePhil]

J'arrive en cours de discussion et je n'ai pas tout lu en détail. Je commente ton dernier MCD, en commençant par des généralites...

1) Vocabulaire
Nomme tes entités avec un nom ou groupe nominal au singulier et tes associations avec un verbe ou groupe verbal à l'infinitif.
Le MCD est la traduction schématique de règles de gestion écrite de cette façon :
" Une sim peut être associée un type_sim et un type_sim peut associer plusieurs sim. "

Pas d'accent dans les noms des entités ou des associations ! Préférer l'underscore au tiret dans les noms. Lors de la création et de l'utilisation de la BDD, cela peut entraîner des erreurs.

2) Dessin
Évite les croisements de traits autant que possible, ça complique la lecture du MCD.
Déplace l'entité Antenne à côté de Stock_Antenne

Passons aux détails...

3) Entité type_sim
Mets un identifiant anonyme qui sera de type entier auto-incrémenté ; le nom_type_sim devenant un attribut clé alternative qui sera muni d'une contrainte d'unicité.

4) Association type_sim -0,n----associer----0,1- sim
Y a t-il des sim sans type ?

5) Entités stock
Est-il nécessaire d'avoir plusieurs entités stock alors qu'elles ont une structure identique ?
Mais peut-être n'y a t-il pas encore tous les attributs dans tes entités ? Ce qui permettrait de les différencier davantage.

6) Entité type_balise
J'espère que les attributs seront au final nommés différemment que parametre1 et parametre2 ! Et si les paramètres ont des valeurs différentes pour chaque balise, il faut déplacer ces attributs dans l'entité Balise.

7) Morceau Client, Service, Véhicule
Il ne devrait pas être isolé du reste du MCD. Comme tes ensembles balise, antenne et sim vont sur les véhicules si j'ai bien compris, il y a une association à faire.

8) Association avoir et compte
Tu vois sur ton schéma que l'ensemble cité ci-dessus fat une boucle. Du coup, un véhicule peut avoir un compte relatif à un client qui n'est pas celui du véhicule !

9) Entité Véhicule
Qu'est-ce que id_provisoire ?

10) Association compte
Cela ressemble plus à une entité qu'à une association !

11) Entité sous-service
Ne faudrait-il pas une association avec une entité service ?