Discussion :

[Rifton007]

Bonjour à vous tous et merci d'avance pour votre aide.

J'ai une table "utilisateurs" avec deux types d'utilisateurs, les clients et les propriétaires de boutiques.
Ainsi qu'une table "boutiques" en relation hasOne.

Quel serait la conception la plus approprié ?

• Créer une table d'association, boutiques_utilisateurs.
• Un champ boutique_id dans la table utilisateurs et attribuer la valeur 0 pour les clients (car ne peuvent être propriétaire d'une boutique)

Encore merci et bonne année à tous,

[escartefigue]

Bonjour

Que voulez vous dire par "Ainsi qu'une table "boutiques" en relation hasOne"
Les cardinalités sous la forme (0,1) (1,1) (0,n) ou (1,n) me parleraient davantage

Si une même personne peut être propriétaire de plusieurs boutiques, alors vous devez avoir une table issue de l'association (relation)

Cela étant, les attributs d'un propriétaire de boutique et d'un clients sont ils vraiment communs ?
N'aurait il pas été plus sage de modéliser 2 entités types différentes et d'en dériver 2 tables distinctes ?
D'autant que les traitements qui concernent les clients et ceux qui concernent les propriétaires sont probablement différents et répartis dans des applications différentes
Avec une table unique, vous créez des contraintes d'exploitation et des difficultés de partage

[fsmrel]

Bonjour et bonne année,


Comme le fait observer escartefigue, "une table "boutiques" en relation hasOne" c’est plutôt vague et ambigu...

Puisque vous utilisez le terme « conception », alors proposez un modèle conceptuel.

Exemple :





Si vous vous intéressez aux fréquentations des boutiques par les clients :




On a procédé à la spécialisation des utilisateurs :

L’entité-type UTILISATEUR factorise les propriétés (et associations) valant à la fois pour les marchands et les clients ;

L’entité-type MARCHAND est porteuse des propriétés (et associations) ne valant que pour les marchands ;

L’entité-type CLIENT est porteuse des propriétés (et associations) ne valant que pour les clients.

Si HasOne signifie qu’un marchand a au moins et au plus une boutique, il faut l’écrire ainsi :

Un marchand a au moins et au plus une boutique.

De même, si HasOne signifie qu’une boutique « a » au moins et au plus un marchand, il faut l’écrire ainsi :

Une boutique est la propriété d’au moins et au plus un marchand.

Dans les diagrammes ci-dessus, un marchand a au moins une boutique et au plus plusieurs ; une boutique est la propriété d’au moins et au plus un marchand ; un client peut fréquenter de 0 à N boutiques et une boutique peut être fréquentée par 0 à N clients.

En fonction de votre préférence, on pourra fournir le diagramme relationnel qui convient.

[Artemus24]

Salut à tous.

Bonne année 2016. Bonne santé. Mes meilleurs Vœux.

Ainsi qu'une table "boutiques" en relation hasOne.

Que veut dire 'hasOne' ?

Je ne fais que réfléchir ici, en exposant quelques idées. Alors ne me tapez pas dessus !
Je donne ma réflexion toute personnelle sur la table utilisateurs et boutiques, avec les deux statuts clients et propriétaires.

Une boutique peut avoir un ou plusieurs propriétaires.
Une boutique peut avoir zéro, un ou plusieurs clients.
(une boutique nouvellement ouverte n'a pas encore de clients.)

Un propriétaire 'possède' une ou plusieurs boutiques.
(un propriétaire sans boutique n'est pas un propriétaire. Aucune raison de créer le statut propriétaire s'il ne l'est pas.)
Un client 'fait ses courses' dans une ou plusieurs boutiques.
(un client qui ne fait pas ses courses n'est pas un client. Même remarque que précédemment pour le statut client.)

Est-ce qu'un client peut-être propriétaire et vice-versa ?
(rien n'empêche qu'un intervenant ait les deux statuts.)

1) si un propriétaire n'est jamais client (et vice-versa) , on peut créer deux tables, l'une des propriétaires et l'autres des clients.
(ces deux tables ont aucune intersection. Elles sont disjointes.)
Boutique sera une table association entre ses deux parents propriétaires et clients.

2) Si un propriétaire peut être aussi client, là, ça se complique.
Il faut être en mesure de faire la distinction entre ces deux statuts (client et propriétaire), sachant qu'il peut être les deux à la fois.
Créer deux tables n'est pas une solution car il y aura des redondances.

Créer une table utilisateur contenant les clients et les propriétaires, avec tout ce qui est commun à ces deux groupes.
Ici, on ne précise pas le statut de l'utilisateur.

Puis ensuite deux tables spécifiques (une par statut) :
--> l'une spécifique aux clients et qui pointe sur la tables des utilisateurs.
--> l'autre spécifique aux propriétaires et qui pointe aussi sur la table des utilisateurs.
On met dans ces tables tout ce qui est spécifique à ces deux statuts.

En ce qui concerne la table des boutiques, elle est une table association entre la table spécifique client et l'autre table spécifique propriétaire.
Elle permet de montrer que le propriétaire d'une boutique peut aussi faire ses courses dans sa boutique.

J'ai une préférence pour la seconde solution car elle me semble plus souple à l'usage.
Que pensez-vous de dissocier les clients et les propriétaires en deux tables spécifiques sachant que la table utilisateurs contient le descriptif général ?

3) donc faire une table regroupant les deux populations n'est pas une bonne idée.
Avec les spécificités du propriétaire et du client, la table sera rempli qu'à moitié.
Je pense qu'il faut disjoindre ces deux statuts en deux tables séparées.

@+

[Rifton007]

Merci de votre participation et vos vœux,

Pour être plus claire:

1. un client ne peut organiser qu'un événement.
2. un événement appartient toujours à un client.
3. un marchand peut avoir une ou plusieurs boutiques.
4. une boutique appartient toujours à un marchand.
5. un utilisateur ne peut être qu'un client ou marchand.

Le diagramme du haut est la structure actuel de ma base de données.
Celui du bas est la nouvel structure en tenant compte de vos avis et conseils.

[fsmrel]

Bonsoir,


D’accord sur la structure du 2e diagramme, à condition de :

— Factoriser l’attribut user_id, c'est-à-dire de le « remonter » dans l’entité-type UTILISATEUR (dealer) ;

— Définir une contrainte de partitionnement (cf. la lunule symbolisant l’héritage) ;

— Nonobstant <ai1>, définir un identifiant relatif pour l’entité-type BOUTIQUE (store) ;

Par ailleurs, si un client organise au moins et au plus un événement (si on en croit votre MCD), l’entité-type CLIENT (customer) devrait absorber l’entité-type EVENEMENT (conséquence de la bijection établie entre les deux entités-types).

[Rifton007]

Merci pour ta réponse fsmrel.

J'ai un peu de mal à comprendre les concepts de modélisation, voici les corrections que j'ai pu appliquer.
Si tu es d'accord, pourrais tu regarder ce nouveau diagramme et me où se trouve mes erreurs.

J'ai remplacer la cardinalité pour customer => event (0,1), un client peu ne pas avoir d'événement.
J'ai remplacer "dealer" par "vendor", ça sonne mieux



Dans ton précédent post, je n'ai pas très bien compris:

Factoriser l’attribut user_id, c'est-à-dire de le « remonter » dans l’entité-type UTILISATEUR (dealer) ;

l’entité-type CLIENT (customer) devrait absorber l’entité-type EVENEMENT

Encore merci,

[fsmrel]

Bonsoir Rifton,

J'ai remplacé la cardinalité pour customer => event (0,1), un client peut ne pas avoir d'événement.

D’accord. Mais dans ces conditions, EVENT est une entité-type faible (weak entity type) relativement à CUSTOMER, car sans le client, un événement n’a pas de sens. Pour éviter les cycles au niveau du MPD, avec PowerAMC il faut rendre EVENT dépendant de CUSTOMER, jouant le rôle de dominant :





Le MCD devrait plutôt ressembler à ceci (j’ai francisé, mais peu importe) :





Et le MPD :





Je suis obligé d’interrompre, on reprendra demain.