Modélisation plusieurs magasins

Bonjour,

J'entre dans le vif du sujet :

J'ai 4 tables :
- Utilisateur
- Siege
- Magasin
- Zone

Les info. dans la table utilisateurs sont présent dans les autres tables, donc naturellement je pense héritage.

Mon "soucis" est qu'un magasin, siège ou zone peuvent avoir 1 ou plusieurs utilisateurs, j'ai donc l'impression que ça "casse" les principes de l'héritage car dans un héritage classique on aura :

Table utilisateur : id, nom, prenom, login, role, passwd etc...

Table Magasin : codeMagasin, nom, ID_UTILISATEUR
Table Siege : adresse, nom, ID_UTILISATEUR
Table Zone : tel, nom, ID_UTILISATEUR

Or si moi je fais ça, un magasin est lié à 1 seul utilisateur, le modèle qui fonctionnerait serait un truc dans le genre là mais je ne sais pas si c'est une bonne pratique :

Table utilisateur : id, nom, prenom, login, passwd, role, ID_TYPE

Table Magasin : id, codeMagasin, nom
Table Siege : id, adresse, nom
Table Zone : id, tel, nom

Et là en fonction du role de l'utilisateur, j'irai chercher (par programmation) l'id de ID_TYPE soit dans la table siege, magasin ou zone

Qu'en pensez vous ? avez vous une meilleure pratique à me recommander ?

En reflechissant un peu plus, je me rend compte que c'est une simple contrainte X que je dois réussir à gérer sous Symfony avec Doctrine 2 :/

En gros soit je fais ça :
Table user :
id
name
...
id_siege
id_zone
id_magasin

et dans ce cas là je me retrouve avec des valeurs null dans zone et magasin si la personne est de type siege.

Soit je fais ça et là je gallère à le gérer avec symfony :
Table user :
id
name
...
id_type

et là l'idée serait de créer un trigger qui détecte si l'identifiant qui se trouve dans id_type est en relation avec la table siege, magasin ou zone.

Votre avis est le bienvenue :)

Bonjour ioexception,


Ça va partir en vrille, il faut revoir le problème sur des bases saines.

Citation:

---

Les info. dans la table utilisateurs sont présent dans les autres tables, donc naturellement je pense héritage.

---

Quand vous dites « les info. » cela sous-entend « les informations descriptives des utilisateur », y compris le nom, et le prénom. Or un magasin n’a pas de prénom, donc il n’y a pas d’héritage. N’oubliez que c’est le verbe « être » qui joue un rôle fondamental, pour ne pas dire exclusif dans le mécanisme de l’héritage, c'est-à-dire à l’occasion de la spécialisation/généralisation des types d’entités : Si M. Volfoni est un utilisateur, il a pour prénom Raoul, mais il n’est ni siège ni magasin ni zone...

Par contre, Raoul travaille dans une unité qui est soit un magasin, un siège ou une zone, auquel cas vous pouvez procéder à la généralisation des types MAGASIN, SIEGE, ZONE en un surtype UNITE : une unité est soit un magasin, un siège ou une zone et un magasin est une unité, un siège est une unité, une zone est une unité. Dans ces conditions, Raoul travaille pour l’unité à laquelle il est rattaché.


Modèle conceptuel des données (MCD)

http://www.fsmwarden.com/developpez_...teurs(MCD).png


Modèle logique des données (MLD)

http://www.fsmwarden.com/developpez_...teurs(MLD).png

Que dire de plus si ce n'est un grand merci. C'est nettement plus propre que ma bidouille.

Je sais maintenant comment gérer ce genre de cas proprement. Encore merci.