Discussion :

[zakblacki]

Bonjour,
étant étudiant on ma demandé de reproduire un site CRM vtiger en utilsant un Framework cakephp pour mieux comprendre j'explique en détails :
1- Donc nous avons un "Users" par exemple Administrateur qui se connecte sur la platforme du site c'est a dire
Une Table "Users" Il se redirige vers le Dashboard
2- Cette Table Users est relié a 4 Autres Table "Prospect" "Comptes" "Contacts" "Affaires"
Mon problème se situe a ce niveau :
- Sachant que chaque page dispose d'un formulaire a remplir avec des Catégories
du genre "Type" ou "Assigné a" ces mêmes sous-catégorie se répète la même chose dans une autre page "Prospect" ou encore "Comptes" donc je vais rajouter de nouvelles Table et les relier
Pour mieux comprendre je vous invite a regarder les images ci dessous
MCD Ainsi que la platforme du Site
Est ce quelqu'un pourrait me guider
Note : je ne sais pas comment appliqué les cardinalité dans ce cas

[aras-vbo]

Bonsoir,

Je pense que vous prenez le problème dans le mauvais sens.
Ce ne sont pas les formulaires d'administration qui doivent dicter la structure de votre base de données ; le formulaire n'est qu'une simple vue sur la base de données (pour afficher ou éditer les données de la base).
Par contre, ces formulaires sont un excellent moyen de définir ce qu'on appelle un "dictionnaire de données", c'est à dire la liste de tous les champs que vous aurez à intégrer (ou non) dans la base.

Deuxième chose importante, définir précisément les termes que vous utilisez dans cette application. Qu'est qu'un compte, au sens de votre application ? Qu'est ce qu'un utilisateur ? Un client potentiel ou celui qui va gérer les clients ? Qu'est ce qu'un prospect ? Qu'est ce qu'une affaire ?

Enfin, définissez les règles de gestion de l'application : qui fait quoi ? A quelles conditions ? Dans quelles limites ? Quels sont les acteurs ? Quelles sont les étapes ? Comment se déroule le passage d'un prospect à une affaire, par exemple ? Qui gère les affaires ? Des utilisateurs normaux ou des commerciaux ?

Définir clairement les éléments de son projet afin qu'ils soient bien compris par ses interlocuteurs aide énormément le concepteur à avoir une vision d'ensemble. Le simple fait d'expliquer le but de l'application et son fonctionnement va faire émerger une structuration et des termes qui deviendront les futures tables de la base.

Vincent

[zakblacki]

Bonsoir,

Merci pour votre réponse

Je vais essayer de reprendre point par point pour que vous arriviez a me suivre, si je suis votre exemple

Nous avons une Table Users (inscrit, login) il hérite de (Prospect, Contact, Affaire, Compte)




Dans cet ordre la

1 - Prospect : (Annuaire) Des Client Potentiel a contacter

2 - Contact : C'est le client d'une Boite Par Exemple (Martin Travaille chez Ayrade)

3 - Comptes : C'est ma Boite elle même (Ayrade)

4 - Affaires : c'est dans la poche le client est soité gagné ou mort (en cours)


Ensuite ces 4 Tables on tous des attribut en commun qui se répète en plus + de Colonnes Par exemple "Assigné a" est relié aux 4 Tables


Donc logiquement je vais relier ces collones en association a de nouvelles Tables

Mais si je suis ce logique la je vais me retrouver avec plusieurs croisement 'X'

Par contre la j'ai pas compris quand est ce que j'applique un héritage ou pas dans une "Catégorie" par exemple ?

Nous avons aussi des champs (SELECT) donc ça sera d'autres Tables aussi en plus a relier



Voici les Tables (Catégorie de collones) qui se répète
Prospect: Assigne, Statut, Secteur, Source Prospect
Contact : Assigne, Statut, Secteur, Source Prospect,
Affaire : Assigne, Type, Source Prospect,
Compte : Assigne, Type, Secteur,
Maintenant soit je let me en Héritage soit je double les liens je ne sais pas
Voici le résultat obtenu

Je n'ai pas encore relier Secteur et Source Prospect sinon ça va me faire des croisement
Autre question pour les attributs des catégories en question je met quoi comme Type de Valeur ?
Par exemple "Assigné a" un nom ça reste un varchar non pas un BOOL ou autre ...

[informer]

Bonjour zakblacki,

Pour qu’une base tienne la route, il faut qu’elle respecte au moins les 3 premières formes normales.

Sur ce site, il’existe d’excellents tuto sur MERISE qui t’expliqueront comment procéder.

Bon courage

[fsmrel]

Bonsoir,


Comme le fait comprendre Vincent, on reste perplexe en examinant votre exposé ; vous prenez le problème à l’envers, en attaquant par le bas : « Nous avons une table "Users" [...] reliée à 4 autres tables... », alors que vous devriez commencer par le haut, en présentant ce qu’il est convenu d’appeler l’univers du discours, c'est-à-dire le sujet que vous traitez, par exemple la prospection (ou autre, si la prospection ne représente qu’une partie du sujet).

Ensuite, comme le fait encore remarquer Vincent, une définition des termes s’impose. Qu’est-ce qu’un « user » (ou plutôt un utilisateur, tant qu’à faire) ? Une personne physique ? Un processus ? Si c’est une personne physique, s’agit-il qu’une personne qui peut prospecter ? faire partie d’une entreprise qui prospecte ? Qui peut être l’objet d’une prospection ?

Vous avez répondu en partie aux interrogations :

Prospect : (Annuaire) Des Client Potentiel à contacter.

D’accord.

Contact : C'est le client d'une Boite Par Exemple (Martin Travaille chez Ayrade)

Au vu de votre exemple, je suppose que par « client d’une boîte » il faut comprendre « collaborateur d’une entreprise » : Martin est un collaborateur de l’entreprise Ayrade. Mais qu’est-ce qu’une boîte (entreprise serait plus séant...), une entreprise prospectée ? Une entreprise qui prospecte ? L’une ou l’autre ?

Comptes : C'est ma Boite elle même (Ayrade)

Ayrade est-elle à considérer en tant qu’entreprise prospectée ? Entreprise qui prospecte ? Autre ?

Faisant partie d’Ayrade, vous considérez-vous comme contact ? Administrateur ? Autre ?

Affaires : c'est dans la poche le client est soité gagné ou mort (en cours)

Ça ne nous éclaire pas. Je suppose que cela a trait au passage pour un entreprise du statut de prospect à celui de client (donc sujette à faire l’objet d’un contrat, intégrer le système de facturation et toutes ces sortes de choses liant fournisseurs et clients). Mais, qu’est-ce qu’une affaire ? (Je suppose que ça n’est ni une entreprise ni une personne physique...)

soit je let me en Héritage soit je double les liens.

On est encore dans le scénario de la charrue avant les bœufs. Rappelons que l’héritage intervient dans la spécialisation/généralisation des entités-types. Ainsi, considérons l’entité-type très générale PERSONNE. Celle-ci peut être spécialisée en PERSONNE PHYSIQUE et PERSONNE MORALE, ce qui impose qu’une personne physique est une personne, et qu’une personne morale est une personne. De même, une personne est une personne physique ou une personne morale. A son tour, une personne physique peut être l’objet d’une spécialisation, même chose pour une personne morale (client, fournisseur, organisme administratif, etc.)

Dans ces conditions, en passant à l’héritage, vous avez spécialisé l’entité-type USER (à franciser et écrire au singulier) en CONTACT, PROSPECT, AFFAIRE et COMPTE, c'est-à-dire qu’un contact est un utilisateur, qu’un prospect est un utilisateur, qu’une affaire est un utilisateur et qu’un compte est un utilisateur. Symétriquement, un utilisateur est un contact, et/ou un prospect et/ou une affaire et/ou un compte.

En vertu de l’héritage, si un utilisateur est une affaire, alors cet utilisateur a un montant, etc. Il y a de quoi être septique.


En l’état, votre MCD est à remettre à plat. Mettez-le sous le boisseau et fournissez le thésaurus des règles de gestion des données. sans oublier la définition et le rôle de chaque entité-type (UTILISATEUR, CONTACT, PROSPECT, AFFAIRE, COMPTE), et le sens précis des relations qu’elles entretiennent. Par exemple, pour reprendre votre 1re tentative de MCD, quel est le rôle de chaque association avec l’entité-type USERS ? A titre d’exemple de règles de gestion des données, voyez par exemple la discussion Société d’audiovisuel, dans laquelle delarita attaque par le bon bout, en énonçant bille en tête les règles de gestion des données, quitte à ce que celles-ci soient affinées et évoluent au fil de la discussion.

Le MCD viendra quand tout cela sera clair et cohérent.

Je n'ai pas encore relier Secteur et Source Prospect sinon ça va me faire des croisement.

En vertu de ce qui précède, cette partie ne pourra être abordée qu’une fois la modélisation des données conforme aux règles de gestion des données.

[fsmrel]

Pour qu’une base tienne la route, il faut qu’elle respecte au moins les 3 premières formes normales.
Sur ce site, il existe d’excellents tuto sur MERISE qui t’expliqueront comment procéder.

Du point de vue théorique, le respect des formes normales concerne chaque table d’une base de données, mais pas cette base à proprement parler (nuance !) En plus, la normalisation n’est pas la panacée : une table peut être en sixième forme normale mais fonctionnellement ne pas être conforme à ce qu’on attend d’elle. De son côté, Merise n’est pas concernée au motif qu’au stade MCD elle ne prend pas formellement en compte le concept de dépendance fonctionnelle (ou plutôt elle a le sien propre, qui au mieux n’est un faux ami).

[informer]

Toute méthode a bien sûr ces limites voir les nombreux posts sur ce sujet mais elle n’en reste pas moins un outil extrême efficace quitte à dénormaliser quand cela est nécessaire.

Respecter le plus possible les 3 formes normales me paraît une exigence.

[fsmrel]

Toute méthode a bien sûr ces limites voir les nombreux posts sur ce sujet mais elle n’en reste pas moins un outil extrême efficace quitte à dénormaliser quand cela est nécessaire.
Respecter le plus possible les 3 formes normales me paraît une exigence.

Normaliser est évidemment... normal, mais pourquoi limiter à 3 formes normales ? Quels en sont les énoncés ? Quelles sont les limites dont vous parlez ? Quand est-il nécessaire de dénormaliser ?

[informer]

Normaliser est évidemment... normal, mais pourquoi limiter à 3 formes normales ? Quels en sont les énoncés ? Quelles sont les limites dont vous parlez ? Quand est-il nécessaire de dénormaliser ?

Pour répondre à ces questions voir tous les tutos et posts sur MERISE qui ont été déjà écrits sur se site.

[fsmrel]

Pour répondre à ces questions voir tous les tutos et posts sur MERISE qui ont été déjà écrits sur se site.

Vous vous défaussez. Je vous demande des réponses précises quant à votre position, et il faudrait l’inférer de la liste des opinions plus ou moins pertinentes exprimées dans le forum Merise depuis 2002 ! Je réitère donc mes questions, merci d’étayer votre position.

Pour sa part, zakblacki doit se demander dans quelle galère il s’est retrouvé.

[elhou80]

Bonjour/Bonsoir Zaki,
j'ai des suggestions et des remarques pour ton schéma :
0- les images ne sont pas visibles pour moi, si c'est possible les attachées en pièces jointes.
1- il est préférable de séparer la table users (les utilisateurs de l'application) et ajouter une colonne dans cette table (date_password) pour garder la traçabilité des mots de passes changés
2- mettre les contraintes (privilèges) pour la manipulation des donnée par profil
alors sous-schema (profilage) est conseillé pour gérer le profilage et la traçabilité des données
(et si vous avez besoin je vous envoyerai les procédures (MCD bien clair)
3- je vois que deux tables contiennent des champs répétés !!!! (nom, prénom, tél, ...etc), il est préférable d'utiliser une seule table (personne) et un autre pour déffirentier la nature (type)
aussi pour les contacts (tél, fax, mail ...etc) vous pouvez créer une table (t_contact) contenant (type contact : tél_fixe, tél_bureau, mail, mobile ) et valeur_contact (contenant les valeurs )
.
la suite j'ai pas pu concentrer dans le schéma car il n'est pas visible

bon courage