Decideo - Actualités sur le Big Data, Business Intelligence, Data Science

Abonnez-vous gratuitement à Decideo !


Decideo

 


Fiche pratique : la technique de surcharge lors de la mise à jour des tables relationnelles


Rédigé par par Funji MATEMU – Expert Informatica le 16 Mars 2011

Il arrive parfois que des utilisateurs nous demandent de modifier la valeur d’un indicateur à partir de plusieurs règles fonctionnelles.

Lorsque cet indicateur se trouve dans une table relationnelle, souvent ces règles impliquent de s’appuyer sur les colonnes qui composent la clef primaire ainsi que sur d’autres.

Dans la suite du document, nous allons montrer que cette technique peut répondre à cette problématique.



Funji MATEMU – Expert Informatica – Communauté des indépendants décisionnels
Funji MATEMU – Expert Informatica – Communauté des indépendants décisionnels
Je fais parti d'une communauté regroupant aujourd'hui une 60aine d'indépendants spécialisés dans le décisionnel. L'objectif de cette communauté est de capitaliser sur les compétences d'experts du métier et de les diffuser vers l'extérieur, afin d'y faire connaître notre expertise. Cette reconnaissance, nous souhaitons l'obtenir :

- par des formations (nous sommes nombreux à donner des formations pour le compte de grands cabinets de formation)

- par la diffusion de fiches :
o de type fiche produit,
o de type best practice (une fiche n'est diffusée qu'après validation du groupe d'experts, dont certains certifiés composés de 4 à 5 personnes)
o de type astuce de développement,

- par du service (prestation d'expertise, de conseil, d'architecture, d'audit) soit directement pour les clients, soit pour le compte des éditeurs à travers leur pôle Professional Services

Contrairement aux fiches de type Best Practice que notre communauté peut publier, cette fiche astuce a un format beaucoup plus court et ne correspond pas à une directive de développement.

C'est un exemple pratique, que vous utilisez peut être déjà pour certains d'entre vous, et que nous trouvons intéressant de diffuser pour ceux qui ne la connaîtrait pas.

J'ai la joie et l'honneur de vous faire part de la première fiche, qui j'espère vous plaira.

Ce document évoque la technique de « surcharge » lors de la mise à jour des tables relationnelles.

Il arrive parfois que des utilisateurs nous demandent de modifier la valeur d’un indicateur à partir de plusieurs règles fonctionnelles.

Lorsque cet indicateur se trouve dans une table relationnelle, souvent ces règles impliquent de s’appuyer sur les colonnes qui composent la clef primaire ainsi que sur d’autres.

Dans la suite du document, nous allons montrer que cette technique peut répondre à cette problématique.

Si vous avez des questions, ou des remarques, n'hésitez pas à nous les faire parvenir. Un espace d'échange est en cours de construction, mais vous pouvez d'ores et déjà nous joindre à l'adresse suivante : expert_informatica@unovia.fr

Tout le travail accompli par ce groupe est fait de façon bénévole, n'hésitez donc pas à les remercier et à les encourager.




Commentaires

1.Posté par Thierry Babulle le 16/03/2011 14:53
Très intéressant.
Merci et bravo : continuez !

2.Posté par Benoit CAYLA le 16/03/2011 17:57
Merci pour cet article clair et concret, qui fait toucher du doigt les possibilités de PowerCenter en matière de Mise à jour. Personnellement je ne suis pas un fan de l'override et trouve plus interressant par exemple la fonctionnalité d'"update strategy" qui est propre à Informatica et qui surtout ,offre une très grande flexibilité. Question de point de vue sans doute, qu'il faut confronter à une réalité projet n'est-ce pas ? le principal étant de toujours s'adapter à un besoin concret dans un contexte lui aussi concret : et là ton article le montre bien.
En tout état de cause et pour rejoindre le commentaire précédent, continuez !

3.Posté par Christophe FOURNEL le 16/03/2011 23:29
Etant un des experts, qui a relu et validé la fiche, et responsable du groupe d'expertise INFORMATICA au sein de cette communauté, je tenais à apporter une précision.
Effectivement, je suis tout à fait d'accord avec Benoit, sur les deux exemples que nous montrons, la condition de mise à jour est porté par un champs du flux et non pas de la Target. Et donc de part les larges possibilités que nous offrent PowerCenter, plusieurs approches peuvent être envisagées pour un même développement. Il est clair que l'Update strategy est une autre approche qui nous aurait permis de flagguer en Update lorsque l'enregistrement validait le nom du fournisseur ou la valeur du profit.
Le cas où nous n'aurions pas le choix, serait si la condition portait directement sur un champs de la Target et pas forcément présent dans le flux.
Comme tu le dis, c'est réellement le contexte projet qui permet de valider l'orientation.
Personnellement, je n'ai pas trop vu de cas, où j'étais confronté à de l'override, et ma consigne aux équipes de développement est de ne l'utiliser qu'en dernier recours.
En effet, les développeurs n'y pensent pas forcément lorsqu'ils écrivent des surcharges (overrride) au niveau du Source Qualifier, du Lookup, de la Target, mais derrière c'est autant de points de vigilance lors d'une migration.

4.Posté par Jacqueline le 17/03/2011 20:33
document tres interessant et clair!
Je reviendrais souvent alors continuez!!

5.Posté par Christophe FOURNEL le 17/03/2011 23:28
Bonsoir à tous,

Au nom de notre communauté, je tenais à vous remercier de l'intérêt que vous suscitez à l'égard de nos différents articles ainsi que vos différents encouragements.

N'hésitez surtout pas, si une problématique vous tient à coeur, de la porter à notre attention et nous serons ravi de répondre à celle-ci par l'intermédiaire d'un article.

Cordialement,

6.Posté par Sébastien MONCEL le 22/03/2011 10:45
Merci Funji et Christophe pour cette initiative !

7.Posté par Soubdhan Michael le 02/04/2011 10:53
Bonjour à tous,
et bien merci aux auteurs pour cette astuce que je ne connaissais pas (en fait je n'aurais même jamais eu l'idée de modifier la requête envoyée au SGBD..)
je note !

mis à part l'astuce,
en ce qui concerne en particulier l'exemple présenté dans la fiche, d'un point de vue pratique nous modifions les requête du SQ directement dans la session, avant ensuite de faire un "Revert".

Michaël

Nouveau commentaire :
Twitter

Vous pouvez commenter ou apporter un complément d’information à tous les articles de ce site. Les commentaires sont libres et ouverts à tous. Néanmoins, nous nous réservons le droit de supprimer, sans explication ni préavis, tout commentaire qui ne serait pas conforme à nos règles internes de fonctionnement, c'est-à-dire tout commentaire diffamatoire ou sans rapport avec le sujet de l’article. Par ailleurs, les commentaires anonymes sont systématiquement supprimés s’ils sont trop négatifs ou trop positifs. Ayez des opinions, partagez les avec les autres, mais assumez les ! Merci d’avance. Merci de noter également que les commentaires ne sont pas automatiquement envoyés aux rédacteurs de chaque article. Si vous souhaitez poser une question au rédacteur d'un article, contactez-le directement, n'utilisez pas les commentaires.


Twitter
Rss
LinkedIn
Facebook
Apple Podcast
App Store
Google Play Store