Discussion :

[cerber943]

Bonsoir,

Je cherche à modéliser une relation entre des Utilisateurs et des Contrats
Les Contrats concernent des Utilisateurs. Chaque contrat concernt forcément un utilisateur mais peut aussi avoir été initié par un souscripteur (qui est lui même un utilisateur potentiel) voir en plus par un installateur (qui est lui aussi un utilisateur potentiel).

Mon contrat peut donc référencer :
- 1 utilisateur
ou
- 1 utilisateur + 1 souscripteur
ou
- 1 utilisateur + 1 souscripteur + 1 installateur.

Dans tous les cas les informations les concernant sont exactement les mêmes (nom prenom, adresse, cp, ville, tél, etc...)

Je m'intéroge sur la solution la plus adaptée à mon problème :
1- mettre 2 attributs à ma table utilisateur (1 attribut "estUnSouscripteur" et 1 attribut "estUnInstallateur")
2- créer une Table souscripteur et une table installateur ayant pour clé primaire une clé étrangere vers ma table utilisateurs.

J'espère avoir été clair dans mon explication désolé par avance si ca n'est pas le cas.
D'après moi les 2 solutions semblent possible, éventuellement la solution 2 me permettrait en terme d'évolutivité de pouvoir ajouter des attributs spécifiques à mes installateurs / souscripteurs, mais mis à part cela je ne sais/vois pas ce que cela change....

Merci d'avance pour toute éclaircissement que vous pourrez m'apporter

[Richard_35]

Bonjour Cerber943,

Intéressante question, sans vérité absolue...

Personnellement, j'ai toujours privilégié la séparation des entités pour la raison que tu indiques

.../... la solution 2 me permettrait en terme d'évolutivité de pouvoir ajouter des attributs spécifiques à mes installateurs / souscripteurs .../...

En revanche, il est dommage de répéter les mêmes adresses si une personne est utilisateur, souscripteur et installateur.

Ma suggestion est la suivante :

Table Personnes :
- Id_Personne (PK)
- Nom
- Prenom
- Adresse
...

Table Utilisateurs :
- Id_Utilisateur (PK)
- Id_Personne (PK)
...

Table Souscripteurs :
- Id_Souscripteur (PK)
- Id_Personne (PK)
...

Table Installateurs :
- Id_Installateur (PK)
- Id_Personne (PK)
...

Relations :
Utilisateurs 1-----1 Personnes via Id_Personne ;
Souscripteurs 1-----1 Personnes via Id_Souscripteur ;
Installateurs 1-----1 Personnes via Id_Installateur.

Les personnalisations sont à étudier. Par exemple, une même personne pourrait avoir un n° de téléphone mobile "souscripteur" et un autre "installateur".

[cerber943]

Bonjour Cerber943,
Les personnalisations sont à étudier. Par exemple, une même personne pourrait avoir un n° de téléphone mobile "souscripteur" et un autre "installateur".

Merci de ta réponse.
En effet cette proposition est intéressante, même si elle ne me parraît pas nécessaire au premier abord, on est jamais trop prudent, les besoins pouvant évoluer...
Dans ce cas concernant les problèmes de la personne ayant plusieures adresses, ne faudrait-il pas mettre l'attribut adresse dans chaque table personne, utilisateur, souscripteur ,... ?

Encore merci

[Richard_35]

Dans ce cas concernant les problèmes de la personne ayant plusieures adresses, ne faudrait-il pas mettre l'attribut adresse dans chaque table personne, utilisateur, souscripteur ,... ?

Cela dépend de la nature des adresses : si, dans ton analyse, une personne peut avoir une adresse "utilisateur", une adresse "souscripteur" et une adresse "installateur", alors oui.

S'il s'agit de gérer plusieurs adresses au niveau de la personne (comme je le suppose), alors non. Dans ce cas, cela pourrait être :

Table Personnes :
- Id_Personne (PK)
- Nom
- Prenom
...

Table Adresses :
- Id_Adresse (PK)
- Id_Personne
- Adresse
...

Je te laisse deviner la relation... il est tard.

[CinePhil]

Nous sommes dans le forum "Schéma", nous allons donc dessiner des morceaux de MCD...

Mon contrat peut donc référencer :
- 1 utilisateur
ou
- 1 utilisateur + 1 souscripteur
ou
- 1 utilisateur + 1 souscripteur + 1 installateur.

Contrat -1,1----Référencer----0,n- Utilisateur
|------------0,1----Référencer----0,n- Souscripteur
|------------0,1----Référencer----0,n- Installateur

un souscripteur (qui est lui même un utilisateur potentiel)
...
un installateur (qui est lui aussi un utilisateur potentiel).

Souscripteur -0,1----Être----0,1- Utilisateur
Installateur -0,1----Être----0,1-----------|

Dans tous les cas les informations les concernant sont exactement les mêmes (nom prenom, adresse, cp, ville, tél, etc...)

Puisqu'il y a les attributs "nom" et "prenom", on en déduit qu'il s'agit de personnes. On peut faire un héritage :
Utilisateur -(1,1)----Être----0,1- Personne
Souscripteur -(1,1)----Être----0,1----|
Installateur -(1,1)----Être----0,1------|

Complétons la partie adresses multiples et téléphones multiples :
Personne -1,n----Avoir----1,1- Telephone -1,1----Typer----0,n- Type_telephone
|---------------1,n----Avoir----1,1- Adresse -1,1----Typer----0,n- Type_adresse
Ville -0,n----Situer----1,1--------------|


Passons aux tables engendrées par ce MCD...
personne_prs (prs_id, prs_nom, prs_prenom...)
utilisateur_uti (uti_id_personne...)
souscripteur_scr (scr_id_personne...)
installateur_ins (ins_id_personne...)
type_adresse_tad (tad_id, tad_libelle)
type_telephone_ttl (ttl_id, ttl_libelle)
ville_vil (vil_id, vil_nom)
adresse_adr (adr_id, adr_id_personne, adr_id_type_adresse, adr_rue, adr_cp, adr_id_ville)
telephone_tel (tel_id, tel_id_type_telephone, tel_numero)
contrat_ctr (ctr_id...)
ctr_referencer_uti_cru (cru_id_contrat, cru_id_utilisateur)
ctr_referencer_scr_crs (crs_id_contrat, crs_id_souscripteur)
ctr_referencer_ins_cri (cri_id_contrat, cri_id_installateur)
scr_etre_uti_seu (seu_id_utilisateur)
ins_etre_uti_ieu (ieu_id_utilisateur)