|
Forums, dernières contributions
COMMENT BIEN CREER UN UNIVERS EMS
est ce que quelqu'un peut me donner des renseignements concrets sur comment creer et mettre en place un univers de A à Z mais surtout quelles sont les precautions à prendre lors de la mise en place de cet univers pour que les données à la sorties soient cohérentes?
ET connaissez vous egalement des sites qui fournissent des exercices pratiques qui peut m'aider à le faire chez le client? Stefan Caracas
Aie , ce sujet est lieu à de nombreux débats , et les bouquins et bonnes pratiques dans la matière font 600 pages :) Je vous conseille de faire un tour des bouquins sortis ( français ou anglais selon possibilités ) sur Business Objects ( eventuellement Designer , j'en ai vu un ou deux ) + faire un tour du didacticiel BO Designer ( environnement de démo fourni avec les CD ).
Je peux vous recommender certains trucs , mais j'aime pas faire de la pub. Faites moi un mail si vous le souhaitez. Cdt , Claire
Bonjour,
Je te remercie de tes infos, j'ai trouvé un manuel de Designer sans didacticiel chez RNI. Où peut-on trouver l'ouvrage dont tu parles comprenant le didacticiel BO Designer ( environnement de démo fourni avec les CD )? Merci par avance. Stefan
Bonjour ,
Toute install de BO contient un environnement de demo à séléctionner lors de l'install. Cdt , Corinne
Sur ce même thème, une question:
deux approches existent pour crer des univers: avec les contextes où toutes les tables seront liées, ou avec les alias (où l'on va construire une étoile par table de fait, et donc duplication des tables de dimensions). D'après vos expériences, y-a-t-il un modèle meilleur que l'autre? Stefan
Bonjour ,
Au fait , les 2 approches ne sont pas vraiment complémentaires , on peut très bien utiliser les 2 dans un même univers , contextes ET alias. Comme d'habitude , tout le 'secret' provient de la compréhension des règles métier qui doivent être à la base de l'univers , dans la pratique on peut s'heurter vite des limites 'techniques' du Designer BO , donc les petites 'bidouilles' sont de mise. L'essentiel étant donc de donner la meilleure vision à l'utilisateur final. Bref : il n'y a pas de meilleure 'école' , c'est l'expérience qui fait le 'magic mix' STEF
Effectivement on peut trouver de tout dans un univers. Par contre, concernant les alias, je trouve preferable de les utiliser dans la 'pure tradition' si on peut dire... (appartenance par exemple de fournisseurs ou clients à un pays, on créera forcement un alias pour lever les ambiguités et résoudre cette notion d'appartenance pour l'une ou l'autre des entités).
Lorsque l'on a plusieurs tables de fait dans un univers, la création de contexte associé est preferable. Il est primordial que la notion de dimension reste toujours unique sauf cas particulier (exemple enoncé precedemment). Les dimensions sont ainsi reliés a autant de tables de fait existentes et l'on peut exploité proprement la notion des clés présentes depuis la version 6. Si des aggregations existent pour des indicateurs identiques et présents sur pluisuers tables de fait, on n'a plus qu'a utiliser la notion de navigation aggregé. La priorité finale restant d'avoir un univers accessible pour les utilisateurs et pas une usine a gaz ou il faut un manuel pour créer meme une requete simple! En dupliquant les dimensions de partout pour moi, c'est... excusez moi, de la merde! Moi je dis toujours q'un bon univers et un univers qui peut être interrogé globalement en une seule requete. Salutations et bonnes fetes! :) Tibo
Je suis completement d'accord avec Stef.
Trop de fois j'ai vu des univers qui étaient montés comme des bases de données opérationnelles. L'univers est alors difficile à apréhender pour les utilisateurs autant que pour les informaticiens qui auront à le maintenir. Les performances ne sont pas forcément efficaces et la justification qui est souvent donnée par les concepteurs est : 'c'est plus simple à alimenter.' Il est sur que copier une base de données opérationnelle pour en faire un univers est simple à alimenter.... mais pensez à l'utilisateur. Il ne pourra pas s'en servir et c'est alors vous qui vous arracherer les cheveux pour faire leurs rapports. Ce que je dis tout le temps à mes clients, c'est qu'un univers doit être accessible par n'importe qui. Il faut donc qu'il soit le plus simple possible quitte à faire des alimentations complexes. N'oubliez pas que les traitements d'alim tournent la nuit. Il vaut mieux qu'un traitement soit un peu plus long que d'avoir un univers tordu qui produira des requêtes incomplètes du point de vue fonctionnel. Bon, je pourrai écrire un romain sur le sujet mais il y en a déjà de très bien et je ne peux que vous conseiller le bouquin de Ralf Kimball sur les entrepots de données. Il vous donne des cas d'étude et explique les notions techniques à avoir pour dessiner des modèles. Perso, à chaque fois que j'ai eu des doutes sur mes modélisations, j'y ai toujours trouvé des solutions simples et efficaces. Tibo Mister Univers
Bonjour,
Tout ce que t'on dit ces personnes est vraie mais tu ne pourra pas créer un univers juste en entandant parler de conexte et d'alias d'abord à quoi va te servir ton univers ? Requête à la demande Ou tableau de bord prédéfini. Dans le deuxième cas l'analyse est toute faite puisque tu connais les requêtes et les données qui vont être restituer. a toi d'organiser les tables et les objets pour te permettre de faire des requêtes plus simple. Le deuxième est plus complexe puisque tu ne peux pas prévoir à l'avance les requêtes des utilisateurs. Donc tu dois au maximum essayer de comprendre quels sont les grands éléments fonctionnels qui guident les utilisateurs dans leur analyse de données. Cela rejoint le message sur les contextes et les alias. Dans les deux cas je te conseille de faire une analyse fonctionnelle et d'essayer de découper ton 'application' en sous ensemble fonctionnel. et après de voir quels sont les éléments techniques qui viennent se calquer dessus. Par exemple focntionnellement les ventes / l'organisation de l'entreprise / le catalogue produits. E t techniquement quels sont les tables qui contiennent les ventes ..... Un autre conseil : il faut essayer d'avoir un modèle de données spécifiques pour sont univers. evite de créer l'univers sur une base opérationnelle cela donne souvent des usines à gaz. Soit tu peux te permettre de créer ta propre base et de faire un modèle tout beau, propre et optimisé. Soit tu peux passer par des vues. Bon courage Je te déconseille les contextes si c'est un univers ouvert à tous, car le concept est difficile à comprendre pour un utilisateur lambda STEF
'Je te déconseille les contextes si c'est un univers ouvert à tous, car le concept est difficile à comprendre pour un utilisateur lambda '
Concernant la derniere remarque et dans une utilisation de multiples tables de faits associés à leur dimension. La notion de contextes est totalement transparente pour l'utilisateur et elle permet au contraire d'adapter les requetes et SQL générés en fonction des objects sélectionnés sans se poser de question. Ce qui est tout de meme le but principal d'un univers, une representaiton fonctionnelle propre ou l'on ne se pose pas de questions techniques pour l'exploiter. Alors justement, dans le cas de modélisation dédié en étoile, j'serai vraiment curieux de voir un univers sans contexte lorsqu'il y a plusieurs tables de faits. Sans, la on a une usine... Sur le reste j'suis ok! ;) Tibo
Un autre point, essaye de faire dès le départ un univers par domaine fonctionnel ; par service.
Un univers qui peut être simple au départ ; trois tables de faits (donc trois contextes à priori) toutes reliées en étoile ; peut par la suite se complexifier avec de nouveaux besoins (nouvelles tables de fait, demande d'aggrégats, etc....). Designer n'ayant pas encore la fonction de calque (ou de couche, ou de sous-modèle...bref une fonction qui permettrait pour un même univers de regarder des vues différentes), tu te retrouves vites à avoir un univers qui peut avoir beaucoup de tables et qui même simple sera difficile à apréhender (et chiant à maintenir). Si donc en plus tu t'es amuser au départ à faire un univers pour plusiseurs domaines fonctionnels, ... bon courage. Ton datawarehouse (la base de données même) peut servir pour plusieurs univers. Ainsi, si tu commences par faire un univers pour les ventes puis qu'arrive un nouveau besoins pour la logistique, ne te dit pas : j'ai ma table des livraisons dans mon univers des ventes, je vais faire mon univers logistique dans celui des ventes et gérer les accès avec Supervisor. Dissocie tes univers des le départ même s'il faut que tu mettes à jours tes tables de dimensions dans les deux univers par la suite en veillant à avoir un vocabulaire commun à l'entreprise. Une solution pour cela, utiliser la notion d'univers maitre... mais ça, je n'ai jamais eu l'occasion de le faire et ne sais pas si ça marche bien. D'ailleurs, si vous avez déjà utilisé cela, qu'en pensez vous ; Mister Univers, Stef ? Stefan
Et nous voilà partis dans la polémique ... :-)
Juste des précisions : 1. Les contextes , quand c'est bien fait , ça ne nuit aucunement à la transparence utilisateur. Bien entendu , la compréhension fonctionnelle/métier/tech doit être à la hauteur de cette finesse de modèllisation. 2. Je suis d'acord qu'un univers sur des ODS ou bases Opérationnelles est habituellement une usine à gaz. Mais la solution avec les vues n'est pas trop mieux coté perf. Autant faire un peu d'effort sur un petit DWH. 3. Tout univers fait sans prise en compte du contexte fonctionnel/métier ira droit dans le mur , ouvrez grand les oreilles aux besoins utilisateur et essayez de vous mettre dans leur 'peau' . Pour les univers maîtres ( liés ) c'est à utiliser avec précaution et pour des fins très spécifiques ( besoins transversaux etc. ) car ça peut vite devenir une usine à gaz aussi. STEF
'Dissocie tes univers des le départ même s'il faut que tu mettes à jours tes tables de dimensions dans les deux univers par la suite en veillant à avoir un vocabulaire commun à l'entreprise. Une solution pour cela, utiliser la notion d'univers maitre... mais ça, je n'ai jamais eu l'occasion de le faire et ne sais pas si ça marche bien.'
Tout a fait d'accord sur ces notions... Concernant la notion d'univers maitre, meme si théoriquement cette dernière semble etre tres séduisante, des bugs et pertes de lien au niveau du réferentiel sont possibles. Et la j'aime autant vous dire que c'est la Merde la plus totale, car les objets deviennent obsoletes losque cette catastrophe vient a arriver. Dans ce cas la, au revoir les documents associés... Il est préferable effectivement de se constituer des classes de dimensions propres dès le départ, avec tout ce qui va bien, conditions predefinies associés etc... pour bien faire, les constituer avec les utilisateurs est encore mieux. Par la suite, des copier/coller simple, permettent d'en faire beneficier tous les univers. De ce fait, les interrogations via les objets restent homogenes entre univers. Plus lourd en maintenance, mais moins risqué... ;) Mister Univers
sur vos remarques toutes très bonnes. les contextes c'est très beaux, mais aller expliquer ça à un utilisateurs non informaticien, j'y crois pas. c'est un très beau concept que bo a trouvé mais cela s'arrête la. Le but des univers ouverts c'est justement de pouvoir croiser des données et recroiser. et les contextes c'est justement cloisonner les données en diffrérenciant des chemins. cela revient à faire plusieurs univers dans un univers. Les alias sont bien plus pratiques et faciles à mettre en oeuvre lorsqu'on est capable de comprendre le besoin des utilisateurs et lorsqu'on est capable de dire non au maitrise d'ouvrage au 'il me faut tout'. c'est vrai que cela multiplie les objets de façon exponentielle. mais avec un peu d'éffort on arrive à un résultat acceptable.
Et mettre des contexte cela n'empêche pas de faire une usine à gaz. Et en terme de maintenabilité c'est ZERO. Sur le DWH ou les datamart, à la place des vues. Quand on peut en faire un c'est bien mieux que les vues, ça c'est sur. Mais on a pas forcément le choix, par exemple sur des applis en maintenance ou dans des entreprises qui n'ont pas les moyens de multiplier les bases de données. La piste des univers maitre c'est pas mal STEPHANE
La notion de contexte était évoqué lorsque on s'en sert de manière détournée pour gérer les tables de faits multiples faisant appel a des tables dimensionnelles communes. Dans ce cas, c'est totalement transparent pour l'utilisateur qui ne les voit jamais, par contre l'univers lui pour le cout tient la route et n'est pas pollué par des redondances qui elles amenent complexités et difficultés pour les utilisateurs. Et en maintenabilité c'est pas plus difficile qu'autre chose, sélectionner trois jointures et les nommer c'est pas extraordinaire...
Et de manière générale pour en revenir au contexte, lorsque utilisé de dans son vrai cadre, je ne vois pas en quoi c'est compliqué pour les utilisateurs. Le problème est souvent ailleurs et en amont. Si effectivement la base de données dédié ne tient pas la route, la c'est un autre débat. La notion d'univers maitre est effectivement TOP mais comme j'disais par expérience j'ai appris à éviter apres perte de liens entre univers. La c'est bye, bye les documents et la correction s'avère lourdre pour les reprendre. 
|
|
|
Ecrire une réponse
