Débutez avec le Designer de Business Objects

Nous venons d'arriver dans l'espace de création de l'univers.
Pour le moment, tout est vide.

Afin de pouvoir créer l'univers, il va falloir sélectionner les tables qui nous serviront.
Pour cela, il suffit de faire un clic droit sur la page blanche, et de sélectionner Tables.

Une fenêtre s'ouvre alors avec la liste des tables, tables qui nous seront pour créer notre univers.

La petite croix à côté de chaque table nous permet d'afficher les champs qu'elle contient.
Un clic droit sur un champ puis Afficher nous permet de visualiser les données qu'il contient.

Pour sélectionner une table, un double clic sur celle-ci suffit. Sachant que nous devons prendre toutes les tables, cette opération est à appliquer sur toute notre liste.

Le Designer a placé toutes les tables les unes à côté des autres. Ceci n'est pas pratique pour avoir une bonne visibilité de l'ensemble des tables.
Nous réorganisons alors les tables en cliquant dans la barre des tâches sur Affichage / Réorganiser les tables.

Nous avons maintenant une visualisation d'ensemble des tables de notre univers.

Nous avons sélectionné les tables qui vont nous servir.
Voyons voir maintenant comment les relier correctement.

Pour relier les tables, il va falloir établir les liaisons entre elles et définir quelles sont les cardinalités.

Commençons par un exemple simple.
Nous prenons la table Country et la table Region.

Le seul champ en commun à ces deux tables est country_id.
je propose nous sélectionnons country_id qu'il nous faut glisser-déposer sur country_id de la table Region.

Nous venons de créer la liaison entre ces deux tables, mais nous n'avons pas encore défini quelles devaient être les cardinalités.
Pour cela, il suffit de double-cliquer sur la liaison. S'ouvre alors cette fenêtre :

Le Designer permet de définir automatiquement les cardinalités. Je suggère toutefois que nous les fassions nous-même, car il est possible que nous ne soyons pas d'accord avec ce qui est proposé.

Si l'on réfléchit, un pays a plusieurs régions, et une région ne fait partie que d'un seul pays.
Nous n'aurons donc qu'un seul pays et plusieurs régions pour cette liaison.
Il faut donc cliquer sur 1 du côté Country et sur n du côté région.

Le Designer nous traduit la relation « avec des mots », ce qui nous permet de vérifier que l'on ne s'est pas trompé.

Nous pouvons alors continuer à relier nos tables les unes aux autres.
Le plus simple est de partir d'une table et continuer le cheminement.

Nous allons maintenant voir le cas d'une liaison un peu plus complexe qu'une simple cardinalité.
Prenons la table Age_group. Elle contient quatre champs :

• age_group_id ;
• age_min ;
• age_max ;
• age_range.

Dans la table Customer, nous ne disposons que d'un champ age.
Nous allons donc déterminer pour la liaison entre ces deux tables que l'âge du client se situe entre l'âge minimum et l'âge maximum d'un groupe.

Nous lions simplement les deux tables, par exemple de age à age_min puis nous éditons la jointure.
Regardons en bas de la fenêtre d'édition de jointure, l'expression de liaison :

Cette expression ne nous convenant pas nous allons appuyer sur le bouton Editer afin de la modifier.
À l'aide des opérateurs fournis, nous précisons que l'âge du client se situe entre l'âge mini et l'âge maxi.

Pour s'assurer de la validité de cette expression, nous pouvons ici encore cliquer sur le bouton vérifier :

Voyons alors la fenêtre d'édition de la jointure :

Nous venons de finir toutes nos liaisons.

Nous allons maintenant voir comment définir les contextes de ce MCD.

En reliant nos tables, nous avons été contraints de créer plusieurs chemins différents, une sorte de boucle qui ne doit pas exister dans un MCD.

Nous allons devoir définir des contextes, c'est-à-dire définir les chemins différents possibles pour le flux de données.
Il suffit pour cela de faire dans la barre des tâches Outils / Détecter les contextes.

Regardons attentivement ce qui se passe alors.

Une fenêtre Contextes candidats s'ouvre avec trois contextes candidats.
Le contexte sélectionné est Age_group et s'il l'on regarde le MCD, on voit un chemin en bleu.
Toutes les liaisons de ce contexte s'affichent en bleu. Le chemin passe bien par les ID des tables.
Ce contexte ne représente pas grand-chose pour nous, car il ne passe pas par « notre boucle ».

Nous pouvons donc cliquer sur le bouton Ajouter afin d'ajouter le contexte.

Le contexte suivant devient plus intéressant : Invoice_Line.
On remarque que le chemin ne passe que d'un côté de la boucle. Automatiquement, le Designer a exclu deux tables afin de ne pas « brouiller » le cheminement des données.

Nous pouvons donc ajouter ce contexte et regarder le dernier Reservation_Line.
Cette fois-ci, le contexte reprend également toutes les tables, mais en passant par l'autre chemin de la boucle.

Nous ajoutons alors ce contexte. Comme le dit l'expression, la boucle est bouclée et nous pouvons appuyer sur OK afin de valider nos contextes.
Désormais, juste au-dessus du MCD, apparaît un encart qui définit nos contextes.

À gauche, nous avons la liste des tables.
Au milieu, nous avons la liste des jointures. En bleu, apparaissent les jointures qui servent au contexte en cours.
À droite, nous avons la liste des contextes. Quand on se positionne sur l'un, les jointures du bleu changent afin que l'on voie lesquelles servent au contexte.

Nous avons vu la définition de nos contextes, regardons à présent comment créer un Alias.

Un alias est une duplication d'une table quand les informations peuvent servir à plusieurs enregistrements.
Dans notre exemple, nous avons une table Pays Country avec deux champs : Country_id et Country.
Nous avons relié cette table à la table client pour sortir le nom du pays où réside le client, au lieu de l'identifiant du pays.
Nous avons également dans cet exemple, une table Resort avec un champ Country_id qui définira le lieu de vacances.

Le pays de résidence du client sera certainement souvent différent du pays de lieu de vacances.
Si l'on souhaite afficher également le nom du pays des vacances, nous allons devoir dupliquer la table Country pour la relier à Resort.
Cela nous permettra d'afficher deux noms de pays différents pour une seule ligne de rapport tandis qu'il y a deux enregistrements dans la table Country.

Pour cela, il nous suffit de cliquer droit sur la table Country puis de choisir Alias.

Il nous faut maintenant donner un nouveau nom de table pour cet alias.
Il faut choisir un nom qui nous permettra de distinguer rapidement les deux tables, donc ici : Country_resort.

Une fois l'alias créé, il n'y a plus qu'à le relier à la table Resort comme vu précédemment.

Nous avons fini notre MCD. Il serait cependant prétentieux d'être assuré de l'avoir réalisé sans erreur. Nous allons donc voir comment les gérer.

Nous venons de relier des tables, déterminer des cardinalités, définir des contextes, etc.
Avant de continuer quoi que ce soit, il est préférable de vérifier la cohérence de nos actes.

Le Designer permet de vérifier automatiquement l'intégrité de ce que l'on a fait.
Pour cela, il faut cliquer dans la barre des tâches sur Outils / Vérifier l'intégrité.

Nous avons accès ensuite à une fenêtre d'invite avec ce dont on souhaite tester ou non l'intégrité.
Par précaution, je préconise de tout le temps cocher la case Vérifier tout. Cela coche automatiquement toutes les cases.
Même si nous n'avons pas créé encore d'objets, le fait que cette case soit cochée n'est pas dérangeant, mais nous pouvons bien évidemment la décocher.

Nous pouvons alors appuyer sur OK afin de lancer la vérification.
Nous obtenons une fenêtre des résultats du test.

La structure est OK, nous avons bien conçu dans l'ensemble notre MCD.
L'analyse des objets est OK, mais il n'y avait pas d'objets à tester.
Nous avons une erreur de jointure. Cliquer sur la petite croix nous permet alors de visualiser l'erreur :

Nous voyons donc que nous avons une erreur entre la table Reservation_Line et la table Service.
Nous allons donc voir sur le MCD ce qu'il se passe :

Nous pouvons constater que nous avons relié le champ Service.service à Reservation_Line.service_id.
La liaison correcte passe en effet par service_id dans les deux tables. Il nous faut corriger cette liaison.

Si nous relançons la vérification avant de continuer, il y a un problème de cardinalité en moins.
Notre problème de jointure corrigé, le problème de cardinalités disparaît.
Regardons les divergences :

Les divergences de cardinalités ne sont pas de réelles erreurs. Si nous sommes sûrs de ce que l'on a fait, on peut passer outre mesure et ne pas s'en soucier.
Il ne nous reste plus qu'à regarder les deux erreurs de contextes :

Les boucles de contextes OK.
Les erreurs viennent de jointures isolées :

Resort_country et Country : nous avons créé l'alias après avoir défini les contextes. Il est donc normal que cette liaison soit isolée. Il nous fait donc la réinsérer dans le contexte ;

Reservation_Line et Service : nous avons modifié suite à une erreur cette jointure. Elle n'appartient donc plus à un contexte et il faut la réinsérer également.

Lorsque les erreurs ont été corrigées, nous pouvons faire une première sauvegarde de notre univers.

Nous allons prendre un nom « simple » pour l'univers : UniversD

Intéressons-nous maintenant aux créations d'objets.