[9i][Best Practice] Conception

Version imprimable

05/12/2006, 17h26
nuke_y

[9i][Best Practice] Conception
Bonjour à tous.

Un bête problème de conception, pour lequel j'ai 2 solutions et je ne sais laquelle choisir.

Soit une architecture de tables pour le domaine RH (en * les champs de la clé) :
Code:

1 2 3 4 5 Identité : - nom - prénom * matricule
Code:

1 2 3 4 5 Revenu : * matricule * mois - revenu
Code:

1 2 3 4 5 6 Affectation : * matricule * mois * service - coefficient
On se fiche dans le problème présent de la table Identité, je ne l'ai mise là que pour la forme.

Mon problème est dans la relation entre Revenu et Affectation.

En effet, un individu a UN SEUL revenu par mois (donc la clé de Revenu est {matricule, mois}).
Mais un individu peut avoir plusieurs affectations par mois : il y a un coefficient par service. par exemple il peut être à 0,6 sur la RH et à 0,4 sur le Commercial.

Donc je créé une ligne pour chaque affectation dans ma table des Affectations.

Jusque là tout va bien. MAIS, car il y a un MAIS, la RH voudrait aussi pouvoir
1) connaître le service sur lequel l'individu est affecté en majorité
2) pouvoir sortir les revenus de l'individu affectés à 100% à ce service là.

Ce qui veut dire que pour Mr TOTO, matricule 001 qui en janvier a gagné 1000€ par mois et qui est affecté à 0,6 à RH et 0,4 au Commercial ils veulent pouvoir faire :

Citation:

TOTO 001 janvier RH 600 €
TOTO 001 janvier Commercial 400 €

et

Citation:

TOTO 001 janvier RH 1000 €

Bon soit, ça ne se discute pas.

Mon problème est le suivant : soit je rajoute une ligne dans ma table des affectations qui contient le service majoritaire avec un coefficient de 1 et un indicateur comme quoi c'est le majoritaire, soit je fait une autre table à côté qui ne contient QUE les services majoritaires. Ce qui donnerait ça :
Code:

1 2 3 4 5 6 7 Affectation : * matricule * mois * service * majoritaire - coefficient
Citation:

MATRICULE MOIS SERVICE MAJORITAIRE COEFFICIENT
001 janvier RH 0 0,6
001 janvier Commercial 0 0,4
001 janvier RH 0 1

ou ça :
Code:

1 2 3 4 5 6 7 8 9 10 11 Affectation : * matricule * mois * service - coefficient Affectation_majoritaire : * matricule * mois - service
Citation:

MATRICULE MOIS SERVICE COEFFICIENT
001 janvier RH 0 0,6
001 janvier Commercial 0 0,4

MATRICULE MOIS SERVICE
001 janvier RH

Quels sont les pour et les contre à votre avis ?

Je serais plutôt pour la 1ere solution : plus simple, plus maintenable, 1 seule table mais une clé plus longue, qui intègre 2 visions différentes de la donnée en 1 seule fois.
05/12/2006, 17h47
plaineR

Bonjour nuke_y

Entre les 2 solutions proposées, la seconde me paraît plus propre (pas de lignes inutiles et faisant de la redondance d'informations dans une table).

Je vois peut-être une troisième solution (si j'ai compris toute l'étendue du problème ;) , pourquoi ne pas sortir le nom du service qui a le plus grand coefficient en t'inspirant de ce qui avait été proposé dans ce post par laurent :
http://www.developpez.net/forums/sho...5&postcount=19
05/12/2006, 17h47
remi4444
Entre ces 2 choix je suis pour le premier mais par contre le flag "majoritaire" ne fait pas partie de la clef, c'est une propriété, pas un identifiant...

petite remarque:
tu sais qu'une toute petite fonction analytique de rien du tout te permetrait de te passer de ton champs ? ;)
Code:

1 2 3 select MATRICULE, MOIS, SERVICE, COEFFICIENT decode ( row_number() over (partition by MATRICULE, MOIS, SERVICE order by COEFFICIENT desc),1,1,0) MAJORITAIRE from Affectation
05/12/2006, 19h39
nuke_y

Je sais, je sais mais

1) le système de requête final doit utiliser Business Objects pour la requête. J'ai pas testé mais ça doit marcher quand même, enfin à tester (j'ai peur de ce que peuvent donner les fonctions analytiques avec des group by made in utilisateurs BO.

2) Ca me gène un peu d'utiliser des fonctions spécifiques à un SGDB alors qu'on se démène depuis tant de temps à faire quelquechose de portable...

Sinon merci des réponses, les avis sont partagés à ce que je vois ;)

EDIT :
Si il est nécessaire, puisque le service majoritaire est AUSSI un service partiel. Sinon il y aura violation de la clé unique.
06/12/2006, 01h21
remi4444

Citation:

Envoyé par nuke_y

Je sais, je sais mais
1) le système de requête final doit utiliser Business Objects pour la requête. J'ai pas testé mais ça doit marcher quand même, enfin à tester (j'ai peur de ce que peuvent donner les fonctions analytiques avec des group by made in utilisateurs BO.

C'est très pratique les fonctions analytique justement pour BO car ce ne sont pas des fonctions de groupement, BO ne génère donc pas de "group by" et ça évite ainsi de faire des gros tris qui rament....

Citation:

Envoyé par nuke_y

2) Ca me gène un peu d'utiliser des fonctions spécifiques à un SGDB alors qu'on se démène depuis tant de temps à faire quelquechose de portable...

Personnellement, j'ai entendu des centaines de fois cet argument, mais j'ai jamais vu ni d'univers, ni d'applicatifs qu'on se soit amusés à porter comme ça...

Citation:

Envoyé par nuke_y

Si il est nécessaire, puisque le service majoritaire est AUSSI un service partiel...

c'est exactement l'argument que j'emploirais pour dire qu'il n'entre pas dans la clef primaire... il doit y avoir un mal-entendu quelque part... :koi:
06/12/2006, 08h27
nuke_y

Citation:

remi4444 a écrit :
Personnellement, j'ai entendu des centaines de fois cet argument, mais j'ai jamais vu ni d'univers, ni d'applicatifs qu'on se soit amusés à porter comme ça...

C'est pas faux :aie:

Citation:

nuke_y a écrit :
Si il est nécessaire, puisque le service majoritaire est AUSSI un service partiel...

Si on prend ce cas là :

Citation:

MATRICULE MOIS SERVICE MAJORITAIRE COEFFICIENT
001 janvier RH 0 0,6
001 janvier Commercial 0 0,4
001 janvier RH 0 1

Je ne peux pas créer une clé primaire sur MATRICULE, MOIS et SERVICE car j'ai un doublon sur 001 janvier RH. Je suis obligé d'inclure MAJORITAIRE dans la clé pour obtenir l'unicité. Ou alors je suis à côté de mes pompes ?
06/12/2006, 09h37
plaineR

Citation:

Envoyé par nuke_y

Je ne peux pas créer une clé primaire sur MATRICULE, MOIS et SERVICE car j'ai un doublon sur 001 janvier RH. Je suis obligé d'inclure MAJORITAIRE dans la clé pour obtenir l'unicité.

D'accord avec toi ;)
06/12/2006, 15h55
remi4444

Citation:

Envoyé par nuke_y

Je ne peux pas créer une clé primaire sur MATRICULE, MOIS et SERVICE car j'ai un doublon sur 001 janvier RH. Je suis obligé d'inclure MAJORITAIRE dans la clé pour obtenir l'unicité. Ou alors je suis à côté de mes pompes ?

Ok, j'avais mal compris en fait... effectivement, il ne vaux mieux pas mélanger les torchons et les serviettes, donc mettre tes lignes de types "majoritaire" dans une autre table car elles signifient autre chose...

Dans ce cas là, suis donc d'accord avec plaineR!
10/12/2006, 15h18
nuke_y

Bon l'utilisateur veut les 2 méthodes pour essayer et comparer laquelle il préfère :aie:

La prochaine fois je lui dirais pas que j'ai plusieurs solutions :roll:

Merci du coup de main
11/12/2006, 09h16
remi4444

sinon tu peux lui en proposer une 3ieme qui serait de ne pas stocker tes lignes "majoritaires" mais de les calculer à la volée dans une requête... :aie:
11/12/2006, 10h14
nuke_y

Je pourrais en fait, mais je les connais bien et je suis sûr qu'ils vont me sortir au moins une fois un type qui a 0,5 sur le service A et 0,5 sur le service B et qui pour une raison historique doit avoir son majoritaire sur B...
11/12/2006, 10h28
remi4444

Dans ce cas, ça veut bien dire que la notion de service majoritaire est une information indépendante (puisque pouvant tolerer potentiellement des exceptions à toute tentative de mise en oeuvre de règle claire...) Donc en tant qu'info indépendante, il parrait clair de la mettre dans une entité indépendante et donc une table indépendante. Si tu fais pas ça, il faudra se creuser la tête à chaque fois que tu feras une requête pour séparer les choses. Tu n'aura à priori jamais l'occasion de faire une requête "tout flag confondu", tu vas donc, pour des raisons pratique sans doute être amené à faire 2 vues pour reconstituer les 2 tables que tu n'auras pas faites :aie: ....
11/12/2006, 10h33
nuke_y

Effectivement dans le cas de requêtes brutes.

Mais mes utilisateurs passent par BO alors la question c'est

Citation:

est-ce que je leur fait prendre un objet différent ou est-ce que j'utilise le même objet mais je gère avec une condition sur le flag ?

Enfin pour moi la réponse est claire hein ? ;)
11/12/2006, 10h47
remi4444

L'esprit de BO (souvent dévoyé par nous autres informaticiens brutaux... ;)), c'est que l'univers doit être fonctionnel, c'est à dire que chaque objet doit porter sa signification propre sans ce soucier de quelquonque impémentation physique et autre flag... donc évidement, quel que soit ton choix de table, il faudra 2 objets... d'autant que si tu les situes bien dans une hierarchie, ça permettra une navigation en profondeur (ça en jette ça généralement ;)). Si tu veux gérer la notion de profondeur en critère de selection, alors tu as les "agregate aware" qui sont fait pour ça si mes souvenir sont bon...
11/12/2006, 10h58
nuke_y

Oui et non.

Par exemple tu prends le cas de mon utilisateur qui passe 3 jours à monter un rapport avec les objets SERVICE et COEFFICIENT. S'il veut l'adapter en utilisant le service majoritaire plutot qu'une multi affectation :

- Dans le cas où je mélange les coeffs par service (majoritaire et multi), il lui suffit de changer le flag (de MAJORITAIRE = 0 à MAJORITAIRE = 1).

- Dans le cas où j'utilise une 2e table pour les coeffs par service, il doit remplacer tous ses objets dans son rapport. Donc refaire ses fournisseurs de données, ses variables, etc.
11/12/2006, 11h14
remi4444

C'est un vaste débat, tu raisonnes d'un point de vue informaticien, mutualisation de la programation etc.. or ce n'est pas l'esprit premier de BO. BO est au départ destiné à des non-informaticiens. Les informaticiens doivent préparer un univers simple avec pour chaque objet une fonction différente. J'avoue que je te donne là une positon de principe alors que dans la pratique, j'ai quasiment toujours vu autre chose :aie:....
Je n'ai pas BO sur moi, mais je crois savoir qu'on peut se tirer tres facilement de la problématique que tu défini tout en restant dans l'esprit, par les "agrégate aware" en faisant un objet qui contient en meme temps les 2 notions (détail et majoritaire) et en jouant sur la présence ou non d'un 2ieme objet du style "consolidation" que tu rend incompatible avec ta notion de détail.