Discussion :

[boutte]

bonjour,

je connais assez bien la suite BO. La grosse valeur ajoutée d'un outil de restitution comme BO est la présence du module Designer permettant de créer des 'univers' : couche sémantique qui permettra ensuite au user final de créer du reporting ad hoc sans se soucier ni du SQL, ni de la modélisation de la base de données sous jacente.

Dans le cas d'une base de données relationnelle et pour la suite Microsoft BI, SSRS pour le Reporting, je ne vois pas l'existence d'un équivalent des 'univers' ...
Dans la BI vue chez Microsoft (SQLServer, BIDS, SSRS ...), cette couche sémantique d'objets Métier existe t'elle ?

si oui, je fais un parallèle avec BO :
quel est l'équivalent du 'Designer' ?
quel est l'équivalent des 'univers' ?

merci de vos infos !

[d.joubert]

La couche Univers, tu l'as dans SQL Server avec les Report Model, mais que pas grand monde a du mettre en place.

Apres, avec un abus de langage, on peut faire un parallèle entre univers et cubes (abus de langage car un cube contient les données alors qu'un univers BO n'est juste qu'une couche sémantique). Ce n'est, en plus, normalement pas le cas d'utilisation d'un cube.

[Jinroh77]

Avec la version 2012, on s'approche pas mal de ce modèle.
PowerPivot permet de définir les univers, à travers on a défini les relations entre les données.
Ensuite, Power View permet de se brancher sur cette source (représentée sous forme de cube, tabulaire) pour que chaque utilisateur crée son propre rapport dans un environnement dédié aux utilisateurs, non développeurs.

[d.joubert]

Pour l'utilisateur, on s'approche du modèle.
Par contre d'un point de vue architecture, je suis pas sûr, car un classeur PowerPivot contient les données alors qu'un univers BO n'est qu'une définition de metadonnées.

[FrancoisJehl]

Par contre d'un point de vue architecture, je suis pas sûr, car un classeur PowerPivot contient les données alors qu'un univers BO n'est qu'une définition de metadonnées.

Pas faux. Mais avec du storage in-memory est ce que cela a encore une importance? Ca voudrait dire qu'on considère qu'un modèle Analysis Services Tabular 2012 en mode DirectQuery est stricto sensu une couche sémantique, alors que passée en VertiPaq cela deviendrait une BdD?
Je pense que QlikTech a clairement fichu en l'air cette notion de couche sémantique, qui n'a je pense de sens qu'opposée à un storage HDD/Cache. Du coup je reste sur ma perception du truc en ce qui concerne les plateformes d'analyse ad-hoc dispo en 2012:

Conçu sur le poste client (i.e. QlikView) -> PowerPivot avec partage sous Sharepoint potentiel. Remplace du coup potentiellement le Designer BO avec la possibilité de remonter côté serveur en modèle Tabular.
Couche sémantique (i.e. relationnel, règles de mapping "simples", Univers BO) -> Analysis Services Tabular
Ad-hoc sur cube (ie: philosophie multidimensionnelle, BW chez SAP-BO) -> Analysis Services Multidimensional (ex-UDM)

Ce qui en passant signifie que l'on a plus de couche de mapping XML vers des bases relationnelles chez Microsoft (à la ReportModel ) ce qui s'en approchant le plus étant un modèle Tabular (en DirectQuery si l'on ne veut pas faire de Refresh explicite). C'est important comme signal. Et à mon sens plutôt positif. Et ça sanctionne une réalité:

La couche Univers, tu l'as dans SQL Server avec les Report Model, mais que pas grand monde a du mettre en place.

En ce qui concerne les frontaux la comparaison est difficile...

Ensuite, Power View permet de se brancher sur cette source (représentée sous forme de cube, tabulaire) pour que chaque utilisateur crée son propre rapport dans un environnement dédié aux utilisateurs, non développeurs.

Oui. Après à voir à l'usage mais en plus des contraintes de licensing (Sharepoint Enterprise ) je ne suis pas sûr que le couple Excel/PowerView sur du Tabular soit capable de remplacer DeskI/WebI sur Univers en termes de complexité d'analyse à court terme. Je radote mais pour moi le problème de SSAS aujourd'hui pour pénétrer chez un pure player BO n'est pas un souci de technique: la synergie Vertipaq/Multidim va s'améliorer et les deux moteurs sont très bons. Techniquement BO va voler c'est évident. On risque plus de se confronter à un souci de frontaux: Excel PivotTable est encore trop light en termes de complexité d'analyse (vs un Procla par exemple) et je dirais la même chose de PowerView, qui est très bon mais doit être secondé par un outil web digne de ce nom pour des contrôleurs de gestion (Procla Web? Dundas OLAP? Tous achetés par MS mais sans suite.). Sans parler de la roadmap PerformancePoint... Mais je m'égare.

[Jinroh77]

Oui. Après à voir à l'usage mais en plus des contraintes de licensing (Sharepoint Enterprise )

Je n'allais pas tout dévoiler d'un seul coup, surtout cette partie qui n'est vraiment pas la plus gaie.
Quand on sait que ce côté reporting vraiment ad-hoc, simple pour les utilisateurs pouvait permettre d'entrer sur les petits compte qui n'ont que du gros reporting de masse, c'est dommage de les assomer avec cela.

Par contre, lorsque que SP est déjà en palce, ça devient un bonheur à proposer


P.S. : Merci pour cette analyse de fonctionnalités

[boutte]

bonjour,

Merci de vos différentes réponses.
Mais, ne connaissant que de très loin la solution MS BI, j'avoue être un peu perdu ... entre "Report Model", "Analysis Services Tabular" ... pour la couche sémantique (= univers sous BO, ou framework sous Cognos)

je vais être + concret en exposant mon besoin :

- INPUT 1 : on a une database de plus de 200 tables, plusieurs tables de faits (en gros : 10 tables "maitres" de faits mais chacune ayant une cascade de niveaux de détails.
Exemple : Table1 des "en têtes facture", Table2 des "lignes de factures", Table3 des "détails de lignes de factures" etc etc).
Et de nombreuses tables de référentiel bien entendu !
Modélisation de la database davantage "opérationnelle" que "décisionnelle" ie on a davantage un infocentre qu'un DWH en bonne et due forme.
Au final, des tables à millions de lignes, plusieurs tera de données ...

- INPUT 2 : on ne va pas passer par du multidim, pas de cubes "fonctionnelles" pour chaque domaine fonctionnel (où 1 domaine fonctionnel est en gros couvert par l'une des 10 tables "maitres" de faits).
Pas de "cube(s)" car on ne va pas dupliquer des tas de tera ...

- nos utilisateurs : besoin de requetage ad-hoc, sur tout et n'importe quelle partie, à tout moment, avec les données "fraiches" de la database (alimentée en temps réel pour info)
on sait qu'avec la suite BO on arriverait à ce que l'on veut : monter un univers BO par "simple" mapping de la database, du webi, et un bon profiling de chaque user afin de ne pas le polluer avec des tas d'objets BO dont il n'aurait que faire (profiling via des droits sur des vues des tables ou profiling direct full BO sur les objets, peu importe)


==> ma question : est-ce qu'il serait possible d'avoir l'équivalent mais pas avec BO (ou Cognos) mais avec la suite MS BI ?

=> En lisant entre les lignes de vos réponses, je comprends que c'est faisable bien entendu mais qu'on n'obtiendrait pas la meme qualité de service (pour les utilisateurs finaux) qu'avec BO.
Je me trompe ?

Merci encore de votre expérience et retour !

salutations

[Ptit_Dje]

Pas faux. Mais avec du storage in-memory est ce que cela a encore une importance?

Je souhaitais juste reagir sur cette phrase.
Le storage in-memory ne l'est pas tant que cela

Voir les screenshots en piece jointe.
Ca ressemble vachement a du SSAS classique...

Il est vrai qu'un job de cleanup passe et retire les cubes non utilises de l'instance.
La structure du cube etant reconstruite basee sur ce qui est stocke dans la DB sharepoint qui va avec le service.

[FrancoisJehl]

est-ce qu'il serait possible d'avoir l'équivalent mais pas avec BO (ou Cognos) mais avec la suite MS BI ?

Oui en 2012 avec du Tabular, à POCer

je comprends que c'est faisable bien entendu mais qu'on n'obtiendrait pas la meme qualité de service (pour les utilisateurs finaux) qu'avec BO.

Si c'est entre mes lignes, alors c'est dingue, c'est pas trop le genre .
Ce que je "reproche" à 2012, c'est d'arriver avec des couches basses innovantes et un Tabular BO killer, mais avec un "trou" fonctionnel entre Excel et PowerView (en gros un outil d'analyse ad-hoc permettant des analyses plus poussées, exploitant plus à fond les moteurs).
Mais la qualité de service de BO... ouais si on rentre pas le temps d'attente dans la qualité de service...

[Jinroh77]

Ce que je "reproche" à 2012, c'est d'arriver avec des couches basses innovantes et un Tabular BO killer, mais avec un "trou" fonctionnel entre Excel et PowerView (en gros un outil d'analyse ad-hoc permettant des analyses plus poussées, exploitant plus à fond les moteurs).

+1

Mais la qualité de service de BO... ouais si on rentre pas le temps d'attente dans la qualité de service...

[Axel_Rose]

je fais renaître ce topic tel un Phoenix de ses cendres
j'ai aussi besoin d'avoir un équivalent pour la couche sémantique de MS BI
ce n'est pas le Data Quality Services et sa base de connaissance ?

[FrancoisJehl]

ce n'est pas le Data Quality Services et sa base de connaissance ?

Non.
Une couche sémantique est une abstraction qui décrit le fait qu'on masque la complexité technique sous-jacente par des entités métiers.
Si on reste sur cette définition, alors tout ce qui se met au dessus du SQL est un semantic layer: en gros un BISM (tabular ou multidim).
Après il y a débat si on est encore une couche sémantique quand on fait du storage, auquel cas en Microsoft ce serait le ROLAP et le DirectQuery qui tiendraient ce rôle.

Mais pas DQS. (dont je t'invite à aller lire la description sur MSDN) Pas plus qu'un lampadaire, un tire-bouchon ou Obi Wan Kenobi.