[POO] Héritage vers Base de données relationelle

Héritage vers Base de données relationelle [POO] - SQL/NoSQL - Programmation

Marsh Posté le 13-09-2011 à 10:35:07    

Bonjour  à tous :)
 
Ha mes cours de POO sont bien loin et je me retrouve face a un problème de base, mais je ne sais pas vraiment vers quelle solution me tournée.
 
J'expose rapido :
 
J'aimerais que chaque [Utilisateur] dispose de :
 
- Plusieurs [Role]
- Plusieurs [Fournisseur] ou Plusieurs [Client]

Traduction :

  • Pour chaque couple ([Fournisseur] et [Utilisateur]) on associe donc UN [Role] (cas des utilisateurs fournisseur)

ou

  • Pour chaque couple ([Client] et [Utilisateur]) on associe donc UN [Role] (cas des utilisateurs client)

ou

  • Un [Utilisateur] n'a nis [Client] ni [Fournisseur] dans ce cas il a uniquement des [Role] (cas des utilisateurs gestionnaire de la plateforme)


Pour résumé :

  • Un utilisateur qui a une liste de Fournisseur, est un utilisateur de type UtilisateurFournisseur
  • Un utilisateur qui a une liste de Client, est un utilisateur de type UtilisateurClient
  • Un utilisateur qui n'a ni Fournisseur, ni Client, , est un utilisateur de type UtilisateurPlateforme


Bien sur je ne vous cite pas les autres propriétés classiques (nom, prénom, adresse, mail, mot de passe etc...)
 
 
Donc je réflechit à un modèle POO puis à une traduction vers la  BDD qui me permettra d'avoir rapidement accès aux utilisateurs, savoir leur type, et récuperer leur liste de role par fournisseur ou par client. (un beau bordel :lol:)
 
 
De base je partais sur un schéma classique :
 
http://yuml.me/diagram/scruffy/class/%5BUtilisateur%5D%5E-%5BUtilisateurFournisseur%5D,%20%5BUtilisateur%5D%5E-%5BUtilisateurClient%5D,%20%5BUtilisateur%5D%5E-%5BUtilisateurPlateforme%5D,%20%5BUtilisateurFournisseur%5D++1-items%20%3E*%5BFournisseur%5D,%20%5BUtilisateurClient%5D++1-items%20%3E*%5BClient%5D
 
Cependant ce schema ne me permet pas d'avoir pour un couple  ([UtilisateurFournisseur], [Fournisseur]) -> UN Role associé
 
J'éspère que vous m'avez compris :p
 
Merci à vous :jap:


Message édité par massanu le 13-09-2011 à 10:36:02

---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Marsh Posté le 13-09-2011 à 10:35:07   

Reply

Marsh Posté le 13-09-2011 à 11:06:53    

J'ai revu un peu le schéma, je ne sais pas si je m'oriente vers la bonne direction :/
 
http://yuml.me/diagram/scruffy/class/%5BUtilisateur%5D%5E-%5BUtilisateurFournisseur%5D,%20%5BUtilisateur%5D%5E-%5BUtilisateurClient%5D,%20%5BUtilisateur%5D%5E-%5BUtilisateurPlateforme%5D,%20%5BUtilisateurFournisseur%5D++1-items%20%3E*%5BFournisseurRole%5D,%20%5BUtilisateurClient%5D++1-items%20%3E*%5BClientRole%5D,%20%5BClientRole%5D-%3E%5BRole%5D,%20%5BClientRole%5D-%3E%5BClient%5D,%20%5BFournisseurRole%5D-%3E%5BRole%5D,%20%5BFournisseurRole%5D-%3E%5BFournisseur%5D,%20%5BUtilisateurPlateforme%5D++1-items%20%3E*%5BRole%5D
 
J'ai ajouter ces deux classes afin de pouvoir accéder donc pour chaque utilisateur à leur liste de fournisseur et de role associé à chacun.  
 
[ClientRole] = Couple Client + Role
[FournisseurRole] = Couple Fournisseur + Role
 
Qu'en pensez vous, n'hésitez pas, si c'est n'importe quoi à le dire :)


---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Marsh Posté le 13-09-2011 à 12:16:59    


 
Merci pour ta participation :)
 
J'ai essayé de comprendre ton diagramme, mais je ne vois pas si il est capable de :
 
Un Utilisateur, peut avoir un Role par Fournisseur (exemple : UtilisateurFournisseur à Role10 pour Fournisseur100, le même UtilisateurFournisseur à Role20 pour Fournisseur200 etc..)
 
Un Utilisateur, n'a qu'un Role unique par Client (exemple : UtilisateurClient à Role10 pour Client100)
 
Un Utilisateur  peux avoir plusieurs Role sur la plateforme (exemple : UtilisateurPlateforme à Role10, Role20 et Role30)
 
CEPENDANT
 
Un utilisateur est SOIT utilisateurClient SOIT utilisateurFournisseur SOIT utilisateurPlateforme
 
Définition :  
- Etre utilisateurClient signifie avoir un Role pour un Client (mais pas pour un fournisseur)
- Etre utilisateurFournisseur signifie avoir au moins un Role pour un Fournisseur (mais pas pour un client)
- Etre utilisateurPlateforme signifie avoir au moins un Role pour la plateforme (mais ni pour un client, ni pour un fournisseur)
 
C'est un peu complexe je sais, mais ce qui rend le probleme encore plus compliqué c'est qu'il faut que je re-adapte la base de donnée et les classes actuelles à ce nouveau système :/
 
Merci à toi FRED82 :jap:

Message cité 1 fois
Message édité par massanu le 13-09-2011 à 12:17:27

---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Marsh Posté le 13-09-2011 à 14:30:32    

Bien vu :) C'est bien plus claire expliqué comme ca :jap:
 
Et bien ca tombe vraiment bien, car c'est comme ca que j'avais commencé à modifier la BDD (en pensant m'être fourvoyé)
 
 
Niveau classe j'obtiendrais donc un truc dans ce genre (je simplifie) :
 

Code :
  1. public class User
  2. {
  3.     private int idUser;
  4.     private string UserName;
  5.     private int idUserType;
  6.     private List<RoleAssociation>;
  7. }
  9. public class RoleAssociation
  10. {
  11.     private int idUser;
  12.     private int? idSupplier;
  13.     private int? idClient;
  14.     private int idRole;
  15. }
  16. public class Supplier
  17. {
  18.     private int idSupplier;
  19. }
  20. public class Client
  21. {
  22.     private int idClient;
  23. }
  24. public class Role
  25. {
  26.     private int idRole;
  27. }


 
 
Qu'en penses tu ?


Message édité par massanu le 13-09-2011 à 14:32:43

---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Marsh Posté le 13-09-2011 à 15:03:36    

D'ailleurs je viens d'y penser mais est-il préférable une structure comme ci-dessus en POO ou plutot en référencant les objets dans les classes ex:
 

Code :
  1. public class User
  2. {
  3.     private int idUser;
  4.     private string UserName;
  5.     private int idUserType;
  6.     private List<RoleAssociation>;
  7. }
  9. public class RoleAssociation
  10. {
  11.     private User _user;
  12.     private Supplier? _supplier;
  13.     private Client? _client;
  14.     private Role _role;
  15. }
  16. public class Supplier
  17. {
  18.     private int idSupplier;
  19. }
  20. public class Client
  21. {
  22.     private int idClient;
  23. }
  24. public class Role
  25. {
  26.     private int idRole;
  27. }


 
Le soucis dans ce cas, c'est que je ne sais pas si on peux définir une classe comme nullable, et si oui est-ce nécessaire (intéressant) point de vue code, ou simplement référencer les id's est suffisant dans les classes.
 
ps : merci pour ton implication, je pose beaucoup de question :/ Mais quoi de mieux pour apprendre qu'une expérience concrète :)
 
Merci encore :jap:


---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Marsh Posté le 14-09-2011 à 09:20:03    

Moi je ferai plutot ca:
 
http://yuml.me/7f806ff7
 
User
Champs classique
Type (not null)
 
RoleClient
UserId
ClientID
 
RoleSupplier
UserID
SupplierID
 
Client
ID
Champs classique
 
Supplier
ID  
Champs classique
 
En fonction du type on sais si c'est un roleclient, rolesupplier ou roleplatforme (ou rolexxx, c'est scalable a l'infini).
Il n'y a qu'un seul type par client, donc un client ne pourrais pas avoir plusieurs role.
Le champ UserID dans RoleClient est unique, donc un User ne peut avoir qu'un seul roleClient.
 
On peut ajouter autant de role qu'on veut (pour le future eventuellement).
C'est aussi normalisé et index friendly.
 
En ce qui concerne les classes, il faut eviter de les mapper directement aux tables, les contraintes imposée par l'integrité referentielle et la normalisation ne doivent pas créer des contraintes en plus dans l'appli. Donc au dessus des tables il faut créer des vues comme une vue UserClient et UserSupplier qui fait directement les joins. Les tables RoleClient et RoleSupplier devraient etre invisible pour l'appli.
 
ps: Ce truc pour faire des diagrames est super :)

Message cité 1 fois
Message édité par Oliiii le 14-09-2011 à 10:17:13
Reply

Marsh Posté le 14-09-2011 à 10:11:56    


 
:jap: merci pour ces précisions  
 
Malheureusement je n'utilise pas de Framework type Entity, mais  juste le framework 2.0/3.5 avec des PS :)


---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Marsh Posté le 14-09-2011 à 10:14:09    

Oliiii a écrit :

Moi je ferai plutot ca:
 
http://yuml.me/diagram/scruffy/cla [...] upplier%5D
 
User
Champs classique
Type (not null)
 
RoleClient
UserId
ClientID
 
RoleSupplier
UserID
SupplierID
 
Client
ID
Champs classique
 
Supplier
ID  
Champs classique
 
En fonction du type on sais si c'est un roleclient, rolesupplier ou roleplatforme (ou rolexxx, c'est scalable a l'infini).
Il n'y a qu'un seul type par client, donc un client ne pourrais pas avoir plusieurs role.
Le champ UserID dans RoleClient est unique, donc un User ne peut avoir qu'un seul roleClient.
 
On peut ajouter autant de role qu'on veut (pour le future eventuellement).
C'est aussi normalisé et index friendly.
 
En ce qui concerne les classes, il faut eviter de les mapper directement aux tables, les contraintes imposée par l'integrité referentielle et la normalisation ne doivent pas créer des contraintes en plus dans l'appli. Donc au dessus des tables il faut créer des vues comme une vue UserClient et UserSupplier qui fait directement les joins. Les tables RoleClient et RoleSupplier devraient etre invisible pour l'appli.
 
ps: Ce truc pour faire des diagrames est super :)


 
 
Merci pour ta participation :jap:
 
Je vois que tu as garder la philosophie de Fred82 en séparant en deux la table liant un [User] et [Supplier] / [Client]
 
Y'a t-il un avantage particulier à ca ?
 
J'ai relu 2,3 fois ton passage sur les vues, ca parait intéressant mais je ne suis pas sur d'avoir totalement saisi le principe, si tu pouvais m'éclairer un peu plus à ce sujet, ca m'évitera surement de faire des bourdes dans le futur :)
 
Merci à toi en tout cas :jap:


---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Marsh Posté le 14-09-2011 à 10:26:50    

Pour que tes tables soient normalisée (http://en.wikipedia.org/wiki/Database_normalization) il faut souvent faire des séparations.
 
Dans ce cas ci ca evite des problemes de contraintes referentielle et ca evite la redondance.
 
L'histoire des vues ca donne un moyen a l'application de "voir" le schema logique des données alors que la DB est créée avec un schema physique.
Dans ce cas ci les tables RoleClient et RoleSupplier sont des tables qui permettent de créer des relations N..N dans une DB, c'est une contrainte purement physique que tu n'as pas besoin d'exposer a ton application.
Avec une vue tu peux n'exposer a l'appli que ce que tu veux en cachant une bonne partie de la popotte interne.

Reply

Marsh Posté le 15-09-2011 à 19:19:32    

HS mais vous les faites avec quel logiciel vos schémas ?


---------------
Bla (blaa bbla)
Reply

Marsh Posté le 15-09-2011 à 19:19:32   

Reply

Marsh Posté le 15-09-2011 à 22:44:24    

thank u ;)


---------------
Bla (blaa bbla)
Reply

Marsh Posté le 16-09-2011 à 15:41:19    

Merci à vous Oliiii et Fred82 :jap:
 
J'ai utilisé vos conseils ca à débloqué la situation ;)


Message édité par massanu le 16-09-2011 à 15:41:31

---------------
Oui je sais, je suis une merde en orthographe et alors ? Altcoin list: https://docs.google.com/spreadsheet [...] =286417424
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed