Question conceptions tables

Version imprimable

03/01/2016, 17h26
Rifton007

Question conceptions tables
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,
04/01/2016, 10h59
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
04/01/2016, 15h52
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 :

http://www.fsmwarden.com/developpez_...n007_mcd_a.png

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

http://www.fsmwarden.com/developpez_...n007_mcd_b.png

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.
04/01/2016, 18h35
Artemus24

Salut à tous.

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

Citation:

Envoyé par Rifton007

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 ! :mrgreen:
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.

@+
04/01/2016, 20h01
Rifton007

1 pièce(s) jointe(s)
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.
Pièce jointe 197013
04/01/2016, 23h12
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).
05/01/2016, 02h36
Rifton007

1 pièce(s) jointe(s)

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 :aie:

Pièce jointe 197040

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

Citation:

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

Citation:

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

Encore merci,
05/01/2016, 04h32
fsmrel

Bonsoir Rifton,

Citation:

Envoyé par Rifton007

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 :

http://www.fsmwarden.com/developpez_...e_faible_a.png

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

http://www.fsmwarden.com/developpez_...007_mcd_v2.png

Et le MPD :

http://www.fsmwarden.com/developpez_...007_mld_v2.png

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

Bonsoir Rifton,

Examinons cette partie de votre MCD :

http://www.fsmwarden.com/developpez_...itage_by_r.png

Je suppose que dans le cartouche du bas de l’entité-type users, « id » désigne l’identifiant (primaire). S’il en est ainsi, dans le monde réel, on aurait par exemple :

users
id         Mail                     username               password
-------    ---------------------    -------------------    --------
1          tryphon@moulinsart.be    Tryphon Tournesol      ********
2          fernand@citron.fr        Fernand Naudin         ********
3          haddock@moulinsart.be    Archibald Haddock      ********
4          raoul@pamplemousse.fr    Raoul Volfoni          ********
5          paul@pamplemousse.fr     Paul Volfoni           ********
6          antoine@mandarine.fr     Antoine Delafoy        ********
7          seraphin@dvp.be          Séraphin Lampion       ********
Si Fernand, Raoul, Paul et Antoine sont des marchands, la situation serait la suivante en ce qui concerne l’entité-type vendors, où l’attribut user_id fait référence à l’attribut id de l’entité-type users :

vendors
id      user_id    store_id    
----    -------    --------
1       2          1
2       4          2
3       5          3
4       6          4
De même, si Tryphon, Archibald et Séraphin sont des clients, la situation serait la suivante en ce qui concerne l’entité-type customers :

customers
id      user_id    event_id    
----    -------    --------
1       1          1
2       3          2
3       7          3
Qu’il s’agisse de vendors ou customers, étant donné qu’il s’agit de sous-types de users (entités-types spécialisées), par définition au niveau du MCD l’attribut user_id y est hérité de l’attribut id de l’entité-type users, et par convention, dans le MCD, il ne doit pas figurer dans les sous-types (l’AGL se chargera de l’injecter dans l’en-tête des tables générées au stade relationnel) :

http://www.fsmwarden.com/developpez_...y_r_rectif.png

D’où le diagramme relationnel produit par l’AGL :

http://www.fsmwarden.com/developpez_...y_r_rectif.png

Dans ce diagramme, On peut observer que la table vendors (on ne parle plus d’entité-type, concept merisien, plus généralement entité-association) a trois clés candidates : {id}, {user_id} et {store_id}. On reparlera plus tard de {store_id}, mais il faut remarquer que, dans leur rôle d’identifiant, les clés {id} et {user_id} font double emploi, l’une d’elles ne sert à rien et peut disparaître. On ne peut pas faire l’économie de l’attribut user_id car il sert à faire le lien avec la table users : dans la table vendors, quand user_id vaut 2, cela veut dire que le marchand correspondant est Fernand. Dans ces conditions, c’est l’attribut id qui disparaît et la partie en cause du MCD doit être réduite à ceci :

http://www.fsmwarden.com/developpez_...by_r_reduc.png

D’où le MPD :

http://www.fsmwarden.com/developpez_...by_r_reduc.png

Et le contenu des tables :

users (inchangé)
id         Mail                     username               password
-------    ---------------------    -------------------    --------
1          tryphon@moulinsart.be    Tryphon Tournesol      ********
2          fernand@citron.fr        Fernand Naudin         ********
3          haddock@moulinsart.be    Archibald Haddock      ********
4          raoul@pamplemousse.fr    Raoul Volfoni          ********
5          paul@pamplemousse.fr     Paul Volfoni           ********
6          antoine@mandarine.fr     Antoine Delafoy        ********
7          seraphin@dvp.be          Séraphin Lampion       ********
vendors
user_id    store_id    
-------    --------
2          1
4          2
5          3
6          4
customers
user_id    event_id    
-------    --------
1          1
3          2
7          3
Venons-en à l’attribut store_id de l’entité-type vendors. Vu son nom, cet attribut caractérise plutôt un magasin qu’un marchand...

Prenons l’exemple suivant, dans lequel cet attribut disparaît de l’entité-type vendors, mais reste bien sûr présent dans l’en-tête de l’entité-type vendors :

users (inchangé)
id         Mail                     username               password
-------    ---------------------    -------------------    --------
1          tryphon@moulinsart.be    Tryphon Tournesol      ********
2          fernand@citron.fr        Fernand Naudin         ********
3          haddock@moulinsart.be    Archibald Haddock      ********
4          raoul@pamplemousse.fr    Raoul Volfoni          ********
5          paulo@pamplemousse.fr    Paul Volfoni           ********
6          antoine@mandarine.fr     Antoine Delafoy        ********
7          seraphin@dvp.be          Séraphin Lampion       ********
vendors
user_id
-------
2
4
5
6
stores
user_id    store_id    storename
-------    --------    ---------
2          1           Chez Fernand
2          2           Le clapier
2          3           Au bon coin
2          4           Chez Mimile

4          1           La Closerie 
4          2           Chez René
4          3           Vive la vie

5          1           La cave à Irène
5          2           Le Villon

6          1           Pique à seaux
6          2           Atout pique
Chaque magasin est identifié par la paire d’attributs {user_id, store_id}. La cave à Irène appartient à l’utilisateur user_id = 5, c'est-à-dire à Paul. Inutile là encore d’ajouter à l’en-tête de stores (mécaniquement...) un attribut « id » qui n’apporte strictement rien.

Quant à l’attribut store_id, conformément à la notation que vous avez utilisée, il s’agit d’un identifiant relatif, permettant de distinguer chaque magasin d’un marchand donné, avec la convention suivante : pour chaque user_id, store_id prend successivement les valeurs 1, 2, 3, etc. (on recommence donc à 1 pour chaque user_id).

En ce qui concerne les événements, l’attribut event_id n’est pas à sa place, il ne peut servir que pour l’entité-type events, mais comme par ailleurs, un client ne peut être à l’origine que d’un seul événement, l’identification relative est donc inutile et event_id peut disparaître définitivement :

customers
user_id
-------
1 
3
7
events
user_id    datum
-------    ----------
1          2016-01-05
3          2016-02-29
7          2016-01-05
Le MCD correspondant est le suivant :

http://www.fsmwarden.com/developpez_..._r_reduc_2.png

Le MLD généré par l’AGL :

http://www.fsmwarden.com/developpez_..._r_reduc_2.png

Tout au long, PowerAMC a repris le nom « id » figurant dans la table users : pour être en phase avec les exemples, on peut renommer cet attribut en « user_id » :

http://www.fsmwarden.com/developpez_...c_2_rename.png

Un script MySQL (à noter la présence de deux triggers pour garantir la contrainte d’exclusion lors des opérations d’insert : un marchand ne peut pas être client et réciproquement) :
USE temp ;

DROP TABLE IF EXISTS events ;
DROP TABLE IF EXISTS customers ;
DROP TABLE IF EXISTS stores ;
DROP TABLE IF EXISTS vendors ;
DROP TABLE IF EXISTS users ;

---------------------------------------------------------------------------------

CREATE TABLE users 
(
   user_id              INT             NOT NULL,
   username             VARCHAR(64)     NOT NULL,
   mail                 VARCHAR(64)     NOT NULL,
   password             VARCHAR(64)     NOT NULL,
   CONSTRAINT USERS_PK PRIMARY KEY (user_id)
) ;

CREATE TABLE vendors 
(
   user_id              INT NOT NULL,
   CONSTRAINT VENDORS_PK PRIMARY KEY (user_id),
   CONSTRAINT VENDORS_USERS_FK FOREIGN KEY (user_id)
      REFERENCES users (user_id)
) ;

CREATE TABLE stores 
(
   user_id              INT             NOT NULL,
   store_id             INT             NOT NULL,
   storename            VARCHAR(64)     NOT NULL,
   CONSTRAINT STORES_PK PRIMARY KEY (user_id, store_id),
   CONSTRAINT STORES_VENDORS_FK FOREIGN KEY (user_id)
      REFERENCES vendors (user_id) ON DELETE CASCADE
) ;

CREATE TABLE customers 
(
   user_id              INT             NOT NULL,
   CONSTRAINT CUSTOMERS_PK PRIMARY KEY (user_id),
   CONSTRAINT CUSTOMERS_USERS_FK FOREIGN KEY (user_id)
      REFERENCES users (user_id) ON DELETE CASCADE
) ;

CREATE TABLE events 
(
   user_id              INT             NOT NULL,
   datum                DATETIME        NOT NULL,
   CONSTRAINT EVENTS_PK PRIMARY KEY (user_id),
   CONSTRAINT EVENTS_CUSTOMERS_FK FOREIGN KEY (user_id)
      REFERENCES customers (user_id) ON DELETE CASCADE
) ;

DELIMITER GO

CREATE TRIGGER VENDORS_EXCLUSION_INSERT BEFORE INSERT ON vendors 
FOR EACH ROW
    BEGIN
        SET @Kount = (SELECT COUNT(*) FROM customers WHERE user_id = NEW.user_id) ;  
        IF @Kount > 0 THEN
            SET @Erreur = CONCAT('Le marchand d''identifiant "', NEW.user_id, '" existe déjà en tant que client. Rejet.') ; 
            SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
        END IF ;            
    END 
GO 

CREATE TRIGGER CUSTOMERS_EXCLUSION_INSERT BEFORE INSERT ON customers 
FOR EACH ROW
    BEGIN
        SET @Kount = (SELECT COUNT(*) FROM vendors WHERE user_id = NEW.user_id) ;  
        IF @Kount > 0 THEN
            SET @Erreur = CONCAT('Le client d''identifiant "', NEW.user_id, '" existe déjà en tant que marchand. Rejet.') ; 
            SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
        END IF ;            
    END 
GO 

DELIMITER ;

INSERT INTO users (user_id, username, mail, password) VALUES
    (1, 'Tryphon Tournesol', 'tryphon@moulinsart.be', '********') 
  , (2, 'Fernand Naudin',    'fernand@citron.fr',     '********') 
  , (3, 'Archibald Haddock', 'haddock@moulinsart.be', '********') 
  , (4, 'Raoul Volfoni',     'raoul@pamplemousse.fr', '********') 
  , (5, 'Paul Volfoni',      'paulo@pamplemousse.fr', '********') 
  , (6, 'Antoine Delafoy',   'antoine@mandarine.fr',  '********') 
  , (7, 'Séraphin Lampion',  'seraphin@dvp.be',       '********') 
;
    
INSERT INTO vendors (user_id) VALUES
    (2), (4), (5), (6) 
;
INSERT INTO stores (user_id, store_id, storename) VALUES
    (2, 1, 'Chez Fernand')
  , (2, 2, 'Le clapier')    
  , (2, 3, 'Au bon coin')
  , (2, 4, 'Chez Mimile')   
  , (4, 1, 'La Closerie')
  , (4, 2, 'Chez René')    
  , (4, 3, 'Vive la vie')
  , (5, 1, 'La cave à Irène')
  , (5, 2, 'Le Villon')    
  , (6, 1, 'Pique à seaux')
  , (6, 2, 'Atout pique')    
;  
INSERT INTO customers (user_id) VALUES
    (1), (3), (7) 
;
INSERT INTO events (user_id, datum) VALUES
    (1, '2016-01-05')
  , (3, '2016-02-29')
  , (7, '2016-01-05')
;  

-- Tentatives d’infraction :

INSERT INTO  customers (user_id) VALUES (2), (6) ; 
INSERT INTO  vendors (user_id) VALUES (3), (7) ;

07/01/2016, 00h03
Rifton007

Juste un tout grand merci pour toutes ces explications détaillées.
J'avais beau lire et consulter des schémas dans ouvrages, des tutoriel.
Mais là tout me parait plus claire.

Merci encore pour le temps que tu as consacré à mon post, fsmrel.
07/01/2016, 00h43
fsmrel

Bonsoir Rifton,

Ce fut un plaisir de vous aider ;)

Bonne route !