Discussion :

[WIM08]

Salut à tous,
ça fait un moment que je galère avec un problème d'analyse, j'ai essayé différentes méthodes, mais rien ne me parait assez convaincant, bon voilà j'expose mon problème.. je m'explique, au fait j'essaye de modéliser et concevoir une base de données qui fait la gestion des Ordres de Paiement. ces OP subissent quelques changements durant le processus de la rémunération, comme la "réception", "renvoi" vers un autre service pour comptabilisation, puis encore leur "réception", puis "renvoi" aux intéressés, et leur "réception" encore une fois si le bénéficiaire n'a pu recevoir l'OP (décès..etc)... Cependant, à chaque étape il y'a de nouvelles propriétés attribuées à l'OP, et je sais vraiment plus comment gérer tout ceci.. j'ai déjà essayé le concept d'héritage, avec l'entité parent "OP" et ses sous-types "OP_envoyés_pour_compta", "OP_envoyés_au_Ben", "OP_retournés"... etc. Pour le moment ça marche.. mais je ne sais pas si c'est très correcte..

Merci.

[fsmrel]

Un scénario possible :

Vous pouvez mettre en œuvre une entité-type OP décrivant les propriétés constantes des ordres de paiement. Pour la partie fluctuante, vous pouvez définir une entité-type faible (ou propriété multivaluée), décrivant les événements vécus par une OP durant sa vie.
Les entités-types faibles font l’objet d’une identification relative (cardinalités 1,1 mises entre parenthèses dans le cas de Power AMC).

Dans l’exemple ci-dessous, l’entité-type faible OPevenement caractérise OP. Chaque événement est horodaté. Les types d’événements font l’objet de l’entité-type EvenementType.

[WIM08]

Merci fsmrel pour votre réponse. Mais ça ne résout pas mon problème.. m'enfin je crois, j'ai peut être pas trop saisie ton scénario... Ma question est, suivant ton exemple, où puis-je mettre alors les nouvelles propriétés qui s'additionne à l'entité OP à chaque événement ?

Voici à quoi ressemble ma BD :
aperçu

Et Merci.

[fsmrel]

Bonsoir WIM08,


Un bon dessin vaut mieux qu’un long discours : votre représentation graphique montre bien qu’on est dans un contexte de spécialisation.

Suite à votre premier message, j’avais cru comprendre qu’il n’y avait qu’un problème trivial, concernant la nature des événements : un ordre de prélèvement pouvant correspondre à une réception, à un envoi, etc. mais rien de plus.

Je comprends votre désarroi suite à la réponse que j’ai faite. En effet, au vu de votre modèle, il devient clair que les événements ont des propriétés spécifiques, et donc je trouve ce modèle correct. De la façon dont vous avez procédé, il s’ensuivra au niveau tabulaire qu’il n’y aura (en principe) pas de nulls, ce qui est très bien.

Si de nouveaux types d’événements avec leurs propriétés propres sont à injecter dans le modèle, l’entité-type OP ne sera pas modifiée, simplement un sous-type viendra se greffer, ce qui ne sera pas une source de problèmes.

Demandez l’avis de TheLeadingEdge ou de JPhi33, mais pour ma part je considère que vous êtes sur la bonne voie.

N.B. Je suppose que vous reverrez le typage des données. Un identifiant de type BLOB, ça paraît curieux (ceci vaut du reste pour les autres attributs)...

[WIM08]

Bonjour,

Merci fsmrel encore une fois pour votre réponse. A vrai dire oui aucun problème ne se pose jusqu'à maintenant.. j'ai juste voulu m'assurer de la justesse de mon analyse.

Pour ce qui est du typage j'ai affecté à quelques identifiants le type "nvarchar" en raison de leur grande taille qui n'arrête de s'accroitre à chaque nouveau enregistrement, je ne sais pas si c'est très correcte, mais j'ai préféré évité un problème de dépassement de taille par la suite, c'est pour ça que j'ai opter pour le type nvarchar. mais si vous avez mieux à me proposer je suis preneuse.

[JPhi33]

Bonjour,

Pour ma part, je trouve aussi cette modélisation correcte sous réserve que tous les scénarios d'enrichissement des Ordres de Paiement aient été envisagés.

Elle pourrait être optimisée en évitant les redondances de données. Par exemple, l'attribut "date_saisie" pourrait ne faire partie que de la table OP, "num_bo" pourrait ne faire partie que de OP_retournes_ordonnateurs, etc.

La contrepartie de l'élimination des redondances est l'obligation de faire des jointures pour obtenir l'ensemble des données d'une spécialisation.


JPhi33

[WIM08]

Salut,
Merci JPhi33 pour votre réponse.
Je prendrai en considération toutes vos suggestions, je marquerai le sujet comme résolu. Merci infiniment