Discussion :

[naunau31]

Bonjour,

J'ai récupéré un tuto sur l'héritage à cette adresse : http://sqlpro.developpez.com/cours/m...tion/heritage/

Ce tuto est vraiment très bien fait et j'ai beaucoup appris à sa lecture. Il y a toutefois une petite chose que je ne comprends pas. Voici le MCD du tuto :




La phrase qui suit ce MCD est la suivante :
"La nature des adresses est soit explicite (attribut UTILITE de l'assocation possède) soit implicite du fait de la relation avec la table des contrats (adresse de facturation ou de commande)."

Et c'est là que je ne comprends pas à quoi sert exactement l'attribut UTILITE.
Merci de vos lumières... et bonne fin de journée à tous.

Arnaud

[CinePhil]

Soit la personne 1 qui possède l'adresse 1.
Si cette personne est un employé, l'utilité de l'adresse sera par exemple 'domicile'.
Si cette personne est un prospect, l'utilité sera par exemple 'professionnelle'.
Si cette personne est un client, l'utilité sera par exemple encore 'professionnelle' mais elle pourra aussi être utilisée par un contrat.

On voit bien que dans le cas de l'employé et du prospect, l'association entre Contrat et adresse n'entre pas en jeu. L'utilité de l'adresse de la personne est alors judicieusement indiquée dans l'association entre Personne et Adresse.

Comme la cardinalité du côté du contrat est (0,1), le contrat a au plus une adresse et on peut supposer qu'il s'agit de l'adresse postale à laquelle envoyer le contrat. On aurait pu aussi ajouter une donnée 'Utilité' à l'association qui aurait pu prendre pour valeurs par exemple 'Facturation', 'Livraison', 'Correspondance'. La cardinalité du côté du Contrat serait alors (0,n).

[naunau31]

Ok je vois mieux l'utilité d'utilité
Et je te remercie au passage d'avoir précisé qu'on pouvait faire de même avec l'association entre Adresse et contrat.

A force d'étudier ce modèle que je trouve particulièrement pédagogique, j'ai trouvé une autre question, ou plutôt une demande de confirmation.

Dans la mesure où Client et Prospect ont la clé étrangère pers_id et pas d'autres données, je suppose qu'on sait qu'une personne est cliente si elle a au moins une commande qui lui est affectée. Autrement dit, une personne qui n'est pas un employé est un prospect sauf s'il a une commande.

Ce passage de l'état de prospect à l'état de client se fait donc par le traitement uniquement. Donc, si dans l'application je veux savoir qui sont les prospects, je dois dans ma requète lister toutes les personnes qui ne sont pas employées et aller voir dans la table commande si son pers_id s'y trouve ?

Arnaud

[CinePhil]

A mon avis, ce n'est pas tout à fait comme ça qu'il faut voir les choses. Sortons un peu du conceptuel et imaginons que la base est installée et opérationnelle avec les logiciels qui y accèdent...

Si je veux créer une action sur un prospect parce qu'un prospect m'a contacté, il faut bien que ce prospect existe dans la table Prospect. Donc on ne crée pas une personne en tant que personne mais en tant qu'employé ou prospect ou client. Le processus du système est plutôt le suivant :

1) Je crée un Prospect.
Le système me demande les renseignements de la personne qui a la qualité de Prospect puis quand je valide :
- Il insère une ligne dans la table Personne avec les renseignements que j'ai donnés
- Il récupère l'id de la personne nouvellement créée et insère une ligne dans la table fille Prospect avec juste l'id de la personne.
- Il cherche si l'adresse de la personne existe et la crée dans la table adresse si elle n'existe pas.
- Il récupère l'id de l'adresse de la personne et insère une ligne dans la table associative Possede.

2) Je crée une action sur le prospect qui m'a contacté
- Le système récupère mon id d'employé et l'id du prospect que je lui ai indiqué (par exemple en le choisissant dans une liste des prospects existants).
- Il insère une ligne dans la table Action avec ce que j'ai saisi comme action.
- Il récupère l'Id de l'action et insère une ligne dans la table associative Contacte.

3) Plus tard le prospect me passe commande et devient client.
Le schéma ne prévoit pas qu'une personne ne puisse apaprtenir qu'à une seule catégorie (employé, prospect, client) ; un employé peut aussi être prospect puis client.

Le système va :
- récupérer l'Id du prospect,
- insérer une ligne dans la table Client avec l'id_personne qui est aussi l'id_prospect récupéré,
- insérer un ligne dans la table Contrat avec les caractéristiques du contrat,
- récupérer l'id du contrat,
- insérer une ligne dans la table associative Commande avec les 3 id.

Avec ce schéma, je peux facilement trouver toutes personnes qui sont à la fois employé, prospect et client : il suffit de joindre les 3 tables ainsi que la table Personne pour récupérer les informations.

[naunau31]

Wow ! Ca c'est de la réponse claire et précise. Tout comme je les aime ! Merci infiniment !

Mais bon je vais me permettre d'être un peu pénible parce qu'il y a encore un petit truc que je voudrais que tu me précises...

On est d'accord qu'un prospect qui a passé une commande est par nature devenu un client.
Si je cherche les "vrais" prospects, c'est-à-dire les prospects qui n'ont pas encore passé de commande, comment je fais ? A mon avis, je dois lister tous les propects (pers_id de la table prospect) puis taper dans la table client et ne conserver que les id qui ne se trouvent que dans la table prospect. J'ai bon ?

Une fois ce point éclairci, je crois que je maîtriserais (enfin !) ce modèle.

Arnaud

[CinePhil]

Si je cherche les "vrais" prospects, c'est-à-dire les prospects qui n'ont pas encore passé de commande, comment je fais ?

Une jointure externe ente Prospect et client et je cherche les lignes de Prospect qui n'ont pas de correspondance dans Client :

Code SQL :

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

1
2
3
4
5
SELECT p.*
FROM Personne p
INNER JOIN Prospect pr ON p.id_personne = pr.id_personne
  LEFT JOIN Client c ON pr.id_personne = c.id_personne
WHERE c.id_personne IS NULL

[naunau31]

Je suis comblé ! Merci, merci, merci... et quoi d'autre encore... ah ben oui : MERCI !

[CinePhil]

De rien.
Par contre, si tu as toutes les réponses à tes questions sur ce sujet, n'oublie pas :