Discussion :

[_medi]

Bonjour,

Je dois faire la conception d’un système d’information d’une société, ce système concerne toutes les informations des clients (produits achetés, quantités,…), des produits, des concurrents (produits, quantités, situation dans le marché, leurs clients, …)

Mais j’ai un problème ! L’entité (ou classe) concurrent sera en relation avec quel entité (classes) ??

Et merci

[hed62]

Salut,

Peux tu envoyer ton ébauche de diagramme s'il te plait ?

A vue de nez, comme ça, je dirais que concurrent sera relié à produit et client.

[_medi]

bonjour,

Je ne peux malheureusement t’envoyé le diagramme ! Car il contient des informations confidentielles concernant la société !

J’ai pensais à faire un héritage entre société et concurrent, et une composition entre société et concurrent (une société à plusieurs concurrents)
Vous en pensé quoi ??


Salutation

[Invité]

Bonjour,

Tes entités devraient ressembler à quelque chose comme ça :

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
20
21
22
23
24
25
26
27
28
29
30
- Produits   : - code produit
               - libellé produit
               - prix unitaire
               - quantité en stock
               - etc.

- Commandes  : - numéro de commande
               - code client
               - code produit
               - quantité
               - date commande
               - etc.

- Clients    : - code client
               - nom client
               - adresse client
               - etc.

- Sociétés   : - code société
               - nom société
               - adresse société
               - etc.

- Concurents : - code société
               - code produit concurent
               - code produit
               - situation dans le marché

- Prospects  : - code client
               - code société

Par entité "concurents", je pense qu'il faut comprendre "produits de la concurence. Il y a donc une entité supplémentaire "Sociétés", non ?

Je m'interroge sur l'attribut "Quantité" de ce que tu appelles "entité concurents".

L'entité "Concurents" est donc en relation avec l'entité "Sociétés" et l'entité "Produits".

L'entité "Clients" comporte les clients de la société et ceux des sociétés concurentes. Un même client pouvant être client de plusieurs sociétés, une entité "Clientèle" me parrait nécessaire, non ?

A vue de nez, comme ça, je dirais que concurrent sera relié à produit et client.

"Concurents" ne devrait pas être relié à "Clients" sinon il y aura une redondance d'un côté ou de l'autre. Si effectivement, on dispose d'une information permettant d'associer "Concurents" et "Clients", c'est qu'il manque une entité équivalente à "Commandes", genre :

Code :

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

1
2
3
4
- Marchés    : - code société
               - code concurent
               - code client
               - quantité (peut-être ?)

Attention ! Lorsqu'il s'agit de commandes, il y a généralement deux entités :

- une entité "Commandes"
- une entité "Lignes de commandes"

C'est une ébauche de MCD... Mais il y a beaucoup de non-dit dans ton énoncé.

Bonne lecture

[_medi]

Merci Ifa pour votre précieuse réponse

Mais moi j’ai procéder comme suite
J’ai fais une classe 'Entreprises' qui aurait des sous-classes 'Clients', 'Prospects' et 'Concurrents', lesquelles hériteraient de la classe 'Entreprise' et auraient leurs propres propriétés non généralisables dans 'Entreprises'.

'Coordonnées' et 'Contacts' pourraient être reliées à 'Entreprises' et contiendraient donc des coordonnées et des contacts des 3 types d'entreprises.

L'avantage de ce système est les coordonnées et les contacts d'un prospect devenu client ne changeront pas de table.

Je me suis basé sur la structure de la base qu’il existe déjà !
J’ai posté cette structure dans une autre discussion voici le lien
http://www.developpez.net/forums/sho...78#post2937778

Votre solution cava changé beaucoup dans la travail que j’ai fais !
Alors je vous demande de voir la schéma de la base de donné (dans le lien) et me disais ce que vous en pensé

[_medi]

Bonjour,

Ifa vous aviez fais une relation directe entre l’entité ‘concurrent’ et l’entité ‘produit’

Mais moi j’ai besoin d’avoir des informations sur les produits de notre société et des in formations sur les produits de nos concurrents dans le marché !!
Alors je pense qu’il faut utilisé une entité intermédiaire entre l’entité ‘produit’ et ‘concurrent’ !? il aura une redondance des informations !

aussi je veux savoir pourquoi utiliser l'entité 'marché' puisque il existe déjà l’entité ‘clientèle’ ??

pourquoi dans l'entité 'marché' il ya code_société et code_concurrent ??

Je vous juste vous rappelé que je modélise en UML alors quand je dis entité = classe !

Merci beaucoup pour tout le mal que vous vous donnez pour me répondre

[Invité]

Bonjour,

Je suis donc allé voir sur ton autre discution. J'ai un sérieux doute sur tes classes puisque tu appelles ça ainsi. Il y a plusieurs relations (1,1) donc ce shéma doit se simplifier.

Par exemple :

- les attributs de "Contacts", de "Coordonnées" et de "Usines_Clients" sont en fait des attributs de "Clients_OCP".

- Dans ton schéma, il n'y a pas d'entité "Produits". En fait, "Produits_Clients" et "Produits_Client&MatièrePremière" ne sont qu'une même entité "Produits".

- Il manque une entité "Composition" permettant de lier "Produits" à "Matières_Premières"

- l'entité "Clients_OCP&Produits" correspond à l'entité "Commandes" et ne devrait pas contenir "ID_usine"

- Dans "Contrats", il manque "ID_Produit"

- etc.

En fait, rien ne va ! C'est le bazard !...

La seule vraie première question à se poser, c'est :

- "Quels sont les objets du monde réel ?"

Réponse :

- Produits
- Matières premières
- Clients
- Commandes
- Contrats
- Villes
- Régions
- Pays

Ajouter :

- Composition (pour lier "Produits" à "Matières premières")

Cette proposition ne tient pas compte des problèmes concernant la concurence. Ce que tu appelles "Prospects", ce sont en fait des "Clients" sans "Contrats". Il reste à éclaircir les produits de la concurrence, vérifier s'il est possible de ne créer qu'une seule entité "Produits" en ajoutant un attribut permettant de distinguer les produits "OCR" des produits de la concurrence. Cela pose le problème de la composition de ces produits concurrents.

A plus tard

[_medi]

Je sais que c’est le bazar dans ce schéma ! D’ailleurs ce n’est pas moi qu’il a fais

Je suis d’accord à avec votre analyse IFA mais comme vous l’aviez dis votre solution ne tien pas compte du problème de la concurrence par railleur mon système il doit contenir des informations sur les concurrents !

Et pour l’entité prospect c’est un acheteur potentiel. Personne que l'on cherche à transformer en client. Alors y a une différence entre prospect et concurrent et aussi mon système dois contenir des informations sur les prospects !
Aussi c’est ça mon problème c’est comment je vais faire pour distinguer les produits de notre société aux produits de la concurrence. Et même question par rapport à nos clients et ceux de nos concurrents ??

Merci

[Invité]

Bonjour,

- Mon système il doit contenir des informations sur les concurrents
- Comment je vais faire pour distinguer les produits de notre société aux produits de la concurrence

- "Produits" et "Produits concurents" peuvent être une même entité. Ce qui les distingue, c'est le "Code_société". L'entité devient une table dans un SGBDR et les produits "OCP" sont une vue de cette table, de même que les produits concurents sont une autre vue de cette même table.

C'est toi qui décide. Les attributs de "Produits" et de "Concurents" peuvent être très différents et imposer deux entités distinctes. Cela dépend également des traitements. Il peut être pertinent de créer deux entités distinctes ne serait-ce qu'à cause des quantités ; au quotidien, ta société "OCP" ne traite pas les produits de la concurence. Dans la réalité, il y a des chances pour que de toutes façon on traite les uns et les autres différemment et donc qu'il ne soit pas particulièrement intéressant de n'en faire qu'une seul entité. N'utiliser que deux vues d'une même table revient à utiliser deux tables.

- Et pour l’entité prospect c’est un acheteur potentiel. Personne que l'on cherche à transformer en client. Alors y a une différence entre prospect et concurrent et aussi mon système dois contenir des informations sur les prospects !

Comment je vais faire pour distinguer nos clients et ceux de nos concurrents

Cela signifie qu'il ne doit exister qu'une seule table "Clients". Les "Clients" OCP se reconnaissent (vue) par l'absence de code "Prospects".

L'entité "Prospects" possédant les attributs spécifiques de ces clients potentiels.

Comme te l'a dit hed62, fais un choix entre tes discutions. Indiques dans celles que tu décides d'abandonner le lien vers celle que tu privilégies. On s'y retrouvera tous.

Au fait, d'où vient ce shéma ? Tu dis que ça existait, il y a vraiment des développement s'appuyant dessus ?

A cet après-midi

[_medi]

Bonjour,

Comme te l'a dit hed62, fais un choix entre tes discutions. Indiques dans celles que tu décides d'abandonner le lien vers celle que tu privilégies. On s'y retrouvera tous.

Je vous propose Ifa de me répondre dans lautre discutions, si vous êtes toujour d'accord pour m'aidé, car j'ai déja posté le diagramme de classes que j'ai fais en suivant vos conseil et celles de Cinephil.
http://www.developpez.net/forums/sho...88#post2941488

Au fait, d'où vient ce shéma ? Tu dis que ça existait, il y a vraiment des développement s'appuyant dessus ?

Beh ce schéma comme je l'avais dis par avant fait partie de mon cahier de charge ! Et oui il y a une application qui s'appuyant dessus, mais ce n'est pas le fruit de mon travail

A ce soir, et merci infiniment