Discussion :

[Sandro Munda]

Bonjour,

Je suis entrain de modéliser un système d'information.
J'ai une entité PERSONNE, celle-ci est enfaite une "super-entité".
Les filles de cette entité sont : JOUEUR, CLIENT, ARBITRE, JOURNALISTE.

Comment puis-je modéliser par exemple le fait qu'un joueur puisse être aussi un client ?

Merci d'avance.

[fsmrel]

Peut-être définir ClientJoueur comme sous-type de PERSONNE et surtype de CLIENT et JOUEUR.

[Sandro Munda]

Bonjour,

Merci de ta réponse.
Le problème est que l'histoire qu'un client peut être un joueur n'est qu'un exemple. Toute les possibilités doivent pouvoir se faire du genre :
Un client peut être joueur.
Un joueur peut être arbitre.
Un client peut être arbitre.
Un journaliste peut être client.

etc...

[CinePhil]

Si tu as des sous-types de personnes, c'est qu'ils ont des attributs différents de ceux d'une personne.
Si certains sous-types ont des attributs communs, tu peux effectivement mettre un nœud supplémentaire à l'arbre des héritages.
Si par contre les attributs d'un sous-type sont tous différents de ceux des autres sous-types, je ne pense pas qu'il y ait de problème particulier.

Personnes(P_Id, P_Nom, P_Prenom, ...)
Client(C_IdPersonne, C_NumClient, ...)
Joueur(J_IdPersonne, J_Pseudo, ...)

Rien n'interdit dans le modèle ci-dessus que M. Jean Dupont, portant l'identifiant 25, soit à la fois un client portant le numéro de client x82463 et un joueur portant le pseudo Toto !

[wazup]

Hum!

Si Un client peut être joueur,
Un joueur peut être arbitre,
Un client peut être arbitre,
Un journaliste peut être client

etc.

je suppose que c'est dans un contexte bien particulier.

Lors d'un match, par exemple ?

(ça manque un peu d'info mais passons, admettons que c'est lors d'un match)

Auquel cas il ne faut pas utiliser l'héritage, car ces qualités (arbitre, client joueur, journaliste) ne sont que des qualité de circonstances, durables pour le temps de ce contexte (appelons-le match par défaut) :

auquel cas ces qualités apparaitrons par le biais d'associations entre une personne et un contexte (un match donc pour rester dans l'exemple) :

modele1 est une première solution non optimisée,

modele2 est la même solution optimisée, présntant le double avantage de réduire le volume, est d'éviter les contraintes de partitions nécessaires, puisque on choisit un discriminant ne pouvant avoir qu'une valeur "a la fois" (qualité)

[Sandro Munda]

Bonjour,

Je suis tout à fait d'accord avec toi.
Mais dans ta deuxième solution, comment puis-je modéliser le fait qu'un joueur possède en plus des attributs d'une personne :

- un numéro de licence
- une catégorie

En gros, comment faire pour ajouter des attributs spécifiques à chaque rôle de la personne ?

Merci beaucoup !

[CinePhil]

Je crois que l'héritage est meilleur.

Un joueur est une personne avec comme attribut spécifique un numéro de licence. Le contexte évoqué par Wazzup est plutôt à considérer lors d'un événement auquel participe la personne en tant que joueur, arbitre...
Un joueur est une personne et peut ou pas participer à des compétitions :
Personne -0,n----Etre----1,1- Joueur -0,n----Participer----0,n- Compétition

Un arbitre est une personne et peut ou pas arbitrer des compétitions :
Personne -0,n----Etre----1,1- Arbitre -0,n----Arbitrer----0,n- Compétition

Ecris tes règles de gestion comme je l'ai fait ci-dessus et le MCD en découlera facilement.

[fsmrel]

Je crois que l'héritage est meilleur.

Un joueur est une personne avec comme attribut spécifique un numéro de licence. Le contexte évoqué par Wazzup est plutôt à considérer lors d'un événement auquel participe la personne en tant que joueur, arbitre...

Cinéphil a raison. Un attribut tel qu'un numéro de licence n'est pas attribué fugacement, à l'occasion d'un événement, contrairement à un dossard lors d'une course de 1500 mètres. Les propriétés spécifiques permanentes amènent à sous-typer.

[Sandro Munda]

Je ne comprends toujours pas comment faire pour dire par exemple :
Un joueur peut-être client.
Un client peut-être arbitre.
Un arbitre peut-être journaliste etc...

Si je fais une entité mère "Personne" qui possède "Joueur", "Client", "Arbitre", "Journaliste" comme entité fille, je n'ai pas envie d'être redondant dans les informations du genre :

Personne
---------
id : 100
Nom : Dupond
Prénom : Alain
Date de naissance : 23/11/1958
Tel : 0499999999
.
.
.

Joueur
------
id : 100
Nom : Dupond
Prénom : Alain
Date de naissance : 23/11/1958
Tel : 0499999999
numLicence : 5000
classement : 10
.
.
.

Ici, il y a redondance des informations ce qui doit, je trouve, être évité.
Comment puis-je faire ?

Merci.

[CinePhil]

Relis mon premier message : je n'y répète pas les attributs de la personne dans le sous-type !

Tu auras donc, pour reprendre ton exemple :
Personne
id : 100
Nom : Dupond
Prenom : Alain
Date de naissance : 23/11/1958
Tel : 0499999999

Joueur
id : 100
numLicence : 5000
classement : 10

Si tu veux récupérer toutes les infos de Alain Dupond:

Code SQL :

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

1
2
3
4
SELECT *
FROM Personne p
INNER JOIN Joueur j ON p.id = j.id
WHERE p.Nom = 'Dupond' AND p.Prenom = 'Alain'

[wazup]

Effectivement, si tu as des informations permanentes et fugitives,
il faut à un moment se poser la question de savoir , comme l'ont justement fait remarquer mes contradicteurs :

- ce qui relève du permanent
- ce qui relève du fugitif

Par exemple, lorsque tu dis :
un joueur peut être arbitre, ce n'est pas dans le même match
par contre, ce joueur a effectivement un numéro de licence en permanence, une catégorie, ainsi qu'un classement (si on considère qu'il s'agit d'un classement permanent, type ATP au tennis ou Elo aux echecs, et non le classement de l'évènement ce que nous ignorons au passage).

Ce qui est certain, c'est qu'on peut difficilement t'aider si on n'a pas une vision globale de ton problème et si tu nous donnes les infos "au compte-goutte".

Ceci dit, si tu réuni toutes les infos dans la classe personne et si tu adoptes la solution que je t'ai proposée, ça marche bien sûr, mais ce n'est guère satisfaisant et rigoureux.

La ou je suis en désaccord avec cinephil, c'est qu'utiliser l'héritage pour des types conjoncturels n'est pas une bonne méthode.

Par contre l'héritage est utile pour modéliser des données permanentes.

Une solution peut donc se trouver dans un mixage des deux approches.

Mais il n'en reste pas moins qu'on a pas assez d'infos pour pouvoir réellement se faire une idée de ton système d'information.

Ici, étant donné que "tout le monde peut être tout le monde" tour à tour,
l'héritage n'est pas adapté en ce qui concerne les associations, car un joueur ne pourra jamais être arbitre quelque soit la stratégie d'héritage.

Par contre, il peut être utilisé pour les informations.

[CinePhil]

La ou je suis en désaccord avec cinephil, c'est qu'utiliser l'héritage pour des types conjoncturels n'est pas une bonne méthode.

Je n'ai jamais dit ça !

Par contre l'héritage est utile pour modéliser des données permanentes.

Bien sûr et c'est ce que j'ai fait !

Ici, étant donné que "tout le monde peut être tout le monde" tour à tour,
l'héritage n'est pas adapté en ce qui concerne les associations, car un joueur ne pourra jamais être arbitre quelque soit la stratégie d'héritage.

Et pourquoi pas ?

M. Dupond peut avoir une licence de joueur ET une capacité d'arbitre ! Comme l'identifiant qui figure dans la table Joueur ou dans la table Arbitre est l'identifiant de la personne, rien n'interdit à une même personne d'être à la fois présente aussi dans la table joueur et dans la table arbitre.

Personne
id : 100
Nom : Dupond
Prenom : Alain
Date de naissance : 23/11/1958
Tel : 0499999999

Joueur
id : 100
numLicence : 5000
classement : 10

Arbitre
id : 100
Capacite : Arbitre régional
AnneeDelivrance : 2007

[wazup]

Mais ce modèle va vraisemblablement impliquer d'utiliser la stratégie d'héritage où on ne conserve que le super-type, et en outre, si tu veux qu'un joueur puisse aussi être arbitre, pas de discriminant de type qui partitionnerait et empêcherai le mélange des genres !

Donc au final on va retomber grosso modo sur le même modèle physique que celui qui serait issu du modèle conceptuel j'ai proposé en modèle2.

Si les autres ont d'autres idées...

[CinePhil]

Le sur-type Personne ne comprend que les données communes à toutes les personnes.
Les sous-types Joueur, Arbitre et autres ne contiennent que les données propres aux sous-types + l'identifiant de la personne à laquelle se rapporte l'information.

Le modèle que tu avais donné était pour des données contextuelles (une compétition). Les exemples que j'ai donnés sont clairs et autorisent qu'une personne puisse à la fois être joueur et arbitre. Par contre, dans les associations contextuelles relatives aux compétitions, on peut supposer qu'un joueur ne pourra pas en même temps être arbitre de cette compétition mais cette fois on ne se sert pas de l'héritage mais des associations qui partent des sous-types pour modéliser la compétition.
Imaginons qu'un match se joue entre deux joueurs et demande un arbitre, on aurait un modèle de ce genre :
Joueur -X--0,n----Participer----2,2- Compétition -1,1----Arbitrer----0,n- Arbitre
| |--------0,n-----------|
|----------------------------------------------X-------------------------------------------|
X représente une exclusion entre les deux joueurs et entre les joueurs et les arbitres. Désolé pour la symbolique mais c'est l'idée.

[wazup]

Effectivement, cinephil a raison,

on peut utiliser un héritage avec totalité.

au temps pour moi.

[wazup]

Par contre, entre les joueurs, les arbitres, les journalistes et les clients, bonjour les contraintes d'exclusion !

Mais c'est bien la solution.

[Sandro Munda]

Bonjour,

Merci beaucoup de votre aide.
Je comprends bien la solution mais, j'aurais une dernière petite question à ce propos.

Si l'identifiant de l'entité Personne est l'id... comment pourrais-je avoir ce genre de chose :

Personne
id : 100
Nom : Dupond
Prenom : Alain
Date de naissance : 23/11/1958
Tel : 0499999999

Joueur
id : 100
numLicence : 5000
classement : 10

Arbitre
id : 100
Capacite : Arbitre régional
AnneeDelivrance : 2007

L'id n'est-il pas unique ?

[CinePhil]

L'Id est unique dans UNE table !
L'Id des sous-types est à la fois clé primaire de la table sous-type et clé étrangère issue de la clé primaire de la table sur-type.

[Sandro Munda]

Clairement.

Je tiens à te remercier CinePhil pour ton explication.
Je remercie également wazup bien sûr

[nec27]

Bonjour à tous,

Je remonte un peu ce topique qui m'intéresse.

J'explique peu mon problème, bien qu'il y ai déjà beaucoup de réponses précises ici.

Je suis en train de développer dans le cadre d'un stage, un site intranet permettant de gérer des stock de matériel informatique.

Pour ce faire, j'utilise phpmyadmin sous wampserveur, et j'avoue avoir du mal à adapter l'idée des sous-types avec cette base de données.

En clair, je dispose d'une table :
--> type_materiel, contenant un id et une designation (clavier, souris, écran, carte mere, etc...)
-->materiel, contenant un id et une quantité, en relation avec la table type_materiel.

|type_materiel|--0.n--avoir--1.1--|materiel|

Cette table materiel est une entité père, où une nouvelle table est créée pour chaque type de matériel. J'ai donc une entité fils souris, une entité fils clavier, etc...

Ensuite donc pour chaque entité fils, je dispose d'autres tables mais je ne m'attarde beaucoup sur cela, juste par exemple le type de connecteur pour un clavier, la langue dans lequel il est conçu...

Tout d'abord, pouvez-vous me dire ce que vous pensez de ce qu'il y a ci-dessus? A force de le retravailler, je commence à me demander s'il est réellement optimisé..


Ensuite, je ne comprend pas trop l'utilisation du "inner join".

Code :

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

1
2
3
4
SELECT *
FROM Personne p
INNER JOIN Joueur j ON p.id = j.id
WHERE p.Nom = 'Dupond' AND p.Prenom = 'Alain'

La jointure au niveau du where ne se fait plus, où n'est pas conseillé ? Ou ce sont juste 2 façons de faire différentes, mais qui reviennent à la même chose ?


Par exemple ne peut on pas écrire :

Code :

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

1
2
3
FROM Personne p, joueur j
where p.id = j.id
and p.Nom = 'Dupond' AND p.Prenom = 'Alain'

Ou alors vu la date du topique, peut être que c'est l'ancienne façon de faire ?
Merci de pouvoir m'éclairer sur ce sujet, bonne journée à tous et à toutes

Nec27