Bonjour à tous !
Dans le même ordre d'idée que le fameux Datawarehouse readiness litmus test de Ralf Kimball (disponible dans son livre : The data warehouse lifecycle toolkit), qui permet de voir si une entreprise, ou ses acteurs, sont prêts à accepter un projet BI. Le TDWI (the data warehouse institute), organisme passant pour être une référence en la matière, nous propose un modèle nous permettant de positionner notre entreprise, ses challenges, ses évolutions et ses contraintes dans un modèle de maturité ma foi très bien pensé.
Le document en question est accessible à cette adresse : http://onereports.inquisiteasp.com/Docs/TDWI_Benchmark_Final.pdf

Je trouve cette méthode excellente pour permettre aux décideurs, et tous les non IT, de se voir dans l'évolution afin de permettre de cadrer et postitionner leurs besoins, attentes et objectifs. Il permet aussi aux professionnels (IT) d'avoir un plan directeur que les décideurs peuvent comprendre, une sorte de langage commun (et dieu sait si les deux ne parlent pas le même langage).

Un très bon complément d'information

J'ai eu un peu de mal à configurer une connection à une source de données Sql Server 2005 sous Talend. Avant de fustiger les solutions Open Source et de me dire que c'est que de la m***, j'ai posté sur notre forum pour voir les retours des gens. Question très fréquemment posée... Et c'est pas la faute à Talend
Il suffit de configurer Sql Server pour qu'il accepte les connection TCP/IP, ça se fait depuis le gestionnaire de configurations de Sql Server. Ensuite, il faut faire en sorte que l'instance fonctionne en mode d'authentification mixte. Et c'est tout !
Les rétissants au changements diront que dans SSIS, pas besoin de faire ça, à cela je répondrais : essayez d'ecrire dans des bases MySql en utilisant SSIS et on rediscutera

Bonjour à tous !
On parle de Dundas comme étant LE third party à avoir pour développer des rapports améliorés dans Reporting Services. En effet, l'outil semble combler tous les manques de Reporting Services (deux axes des Y, combinaisons de graphes, nouveaux types de graphes, jauges, indicateurs de performance, etc.).
Le problème, parcequ'il doit toujours y en avoir un, c'est que je développe en ce moment une solution de reporting qui utilise de très petits nombres (inférieurs à un), et que dans ce cas là, les rapports Dundas ont un comportement assez étrange : il n'affichent plus les valeurs d'échelle de l'axe des Y... Je me dis que la communauté Dundas va vite faire de régler ça alors je poste dans leurs forum (en même temps que chez developpez.com ). Mais il semble que nos amis de chez Dundas soit assez sélectifs quand aux personnes à qui ils doivent répondre. Je comprend que les personnes qui ont signés des ententes de services doivent passer en priorité... Mais de là à ignorer tous ce qui reste (des acheteurs potentiels)... Pas fort de leur part.
En attendant, je me tourne vers d'autres solutions, si elles existent, pour régler mon problème.
Edit : le problème est ENFIN résolu.
La solution, fournie par l'équipe de support de Dundas, est d'utiliser l'API Dundas pour calculer les intervalles. Attention, pour avoir des reponses chez Dundas, il faut envoyer les questions par mail à leur équipe de support (pas très communautaire tout ça).
Voici ce que j'ai fait :
 
DataPoint maxPoint = chartObj.Series[0].Points.FindMaxValue(); 
//donne la plus grande valeur de mon graphe 
 
double theMaxValueOfMYLine = maxPoint.YValues[0]; 
//donne la valeur du Y du point 
chartObj.ChartAreas[0].AxisY2.Interval = theMaxValueOfMYLine / 5; 
//spécifie l'intervalle de l'axe des Y (le second). J'ai choisi de prendre la plus grande valeur et la diviser par 5, 
//ainsi j'ai 5 intervalles dans mon axe des Y  


Le bulk load mode, dans Sql Server 2005, permet de faire des inscriptions minimales dans le journal d'une base de données lorsqu'on fait des chargements en bloc (BULK LOAD). L'intéret ? Et bien imaginez que vous ayez très peu de temps pour charger une ennorme quantité d'information dans votre table... Vous seriez bien contents de vous passer des ecritures autres que celles faites dans la base de données, notemment les ecritures dans le journal. Votre traitement serait beaucoup plus rapide.
Autre cas, vous chargez des données dans votre entrepôt et vous cherchez un moyen facile de pouvoir revenir en arrière après un chargement. Et bien puisque le bulk load mode n'écrit pas les données chargées en bloc dans le journal. Il vous suffit de faire une restauration de la base de données au dernier point dans le journal et le tour est joué !
Cependant ! ce mode de journalisation ne fonctionne pas toujours comme on veut ! En effet certaines conditions doivent être respéctées pour pouvoir journaliser en bloc :
- La table doit être vide
OU
- La table ne doit contenir AUCUN index cluster.
Je sais, c'est bien contraignant tout ça, surtout qu'on a pas la chance d'avoir une table vide tout le temps... Mais les avantages sont la, et une bonne pratique en B.I est de désactiver les index avant les chargements. Dans un package SSIS, ça se fait facilement

Bonjour à tous,
Ayant passé un petit moment avec PPS (Performance Point Server). Je vous confie mes premières remarques et impréssions.
Premièrement, une petite présentation :
PPS est L'OUTIL de dashboarding (tableaux de bords et indicateurs) de microsoft. Sorti en décembre de l'année passée, ce composant Business Intelligence est censé répondre à toutes les demandes des consommateurs d'informations (analystes, directeurs, décideurs), offrant fléxibilité, performance, facilité d'utilisation, blablabla.
PPS se compose de deux partie : une partie "backend", représentée par le business modeler, et une partie "création de dashboards" représentée par le fameux "dashboard designer". Nous en parlerons plus tard ...

» Lire la suite!

Bonjour,
L'installation de proclarity 6.0 (et même les autres versions je suppose) ne fonctionne pas si le mode d'identification SQL est à Windows Seulement. Il faut que ce dernier soit à "Mode Mixte". Proclarity ayant une partie Web, et ayant une base de données SQL Server à installer. Il est necessaire d'avoir ce mode d'identification pour la connection.

C'est en installant le SP2 de Reporting Services que je me suis rendu compte que mon serveur de rapports n'était plus disponible. Une erreur me signalant que rsReportServer.config était inaccessible... Du MS pur et dur, un service pack censé réglé des bugs en créé d'autres...
En tout cas ! L'excellent Fabrice Romelard a trouvé le fix de ça :
- Aller au compte SQLServer2005ReportingServicesWebServiceUser$XXXX$MSSQLSERVER dans la gestion de l'ordinateur et y ajouter les comptes ASPNET et NETWORK SERVICE (s'il n'y sont pas déjà)...
- Aller au fichier de configuration rsReportServer.config (généralement dans C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\ReportServer) et donner au groupe précédement mentionné les droits de lecture et d'exécution.
- Jetter un coup d'oeil dans la configuration de Reporting Services pour voir que l'accès à la base de données de rapports s'effectue avec le compte que vous voulez (compte de domaine de préférence).

Voila voila !

Amis et amies néophytes, c'est ici que ça se passe !!
Un très bon moyen d'avoir un premier contact avec la suite B.I de MS ainsi qu'avec Sql Server (2000, 2005, 2008) : les virtual labs !
Pour ceux qui ne connaissent pas le principe, c'est une machine que MS met à la disposition des utilisateurs de façon virtuelle, c'est à dire que vous avez une page Web qui affiche un poste de travail (comme si vous aviez un pc dans votre pc
Très simple à prendre en main et très bien documenté, les virtual labs permettent de suivre des étapes simples pour produire un résultat montrant la puissance et la simplicité de l'outil.

Un très bon départ qui pourra se poursuivre avec les tutos de DVP

Voici le lien vers les virtual labs de la suite Business Intelligence de MS : http://technet.microsoft.com/en-us/bb499788.aspx

Enjoy !

Bonjour à tous,
Un message d'erreur qui m'a fait hérisser les poils pendant que je m'atelais à l'apprentissage de Reporting Services... Je n'arrivais pas à installer Reporting Services car le message suivant bloquait l'installation : "SQL Server Setup failed to obtain system account information for the ASPNET account".
Avant toute chose, il faut que vous aillez IIS d'installé sur votre ordinateur (Report Server se base sur IIS pour déployer et gérer ses sites Web).
- Dans panneau de config -> Outils d'administration -> Double cliquez sur IIS (internet services).
- Choisissez le dossier "sites web" et affichez les propriétés.
- Dans l'onglet ASP.NET, choisissez une version de ASP.NET (si vous n'avez qu'un seul choix, tant mieux...)
- ouvrez une invite ms-dos et allez dans Windows\Microsoft.NET\Framework\v"votre_numero_de_version_ASP". Ce numéro est biensur celui que vous aviez choisi au niveau de la gestion de IIS.
- Tapez ensuite la commande : aspnet_regiis -i. Une installation commencera et vos problèmes seront réglés
Voila voila !

Je viens de lire un article (critique très intéressante) sur l'état et l'avenir de l'OSBI au moment ou j'écris ce billet.
C'est vrai qu'on commençait à se lasser d'entendre dire que l'open source BI n'est pas encore mature et qu'il lui reste du temps avant de conquérir les marchés. Sans oublier les "fanatiques" de l'OSBI qui prônent le : "nos outils sont les meilleurs, et si vous ne les utilisez pas, c'est que vous êtes de gros nuls !".
Je trouvais, et trouve encore, que ces discours étaient teintés d'une subjectivité très subtile... Sérieusement, les critiques concernant l'OSBI sont dénuées de chiffres, de faits, de choses tangibles qui nous aident à nous faire notre opinion.
C'est pour cette raison que je fût très heureux de lire cet article de Jeff Kelly, sur le site searchDataManagement.com (site que je conseilles fortement à ceux qui font de la veille B.I) et qui s'intitule : "Open source BI stands to gain ground in a tight economy". Lire l'article

Voici les points qui m'ont marqué ainsi que mon appréciation personnelle :

- La communauté OSBI s'accroit de mois en mois : nous avons enfin des chiffres !!! Bon, ça reste des chiffres fournis par les compagnies elles mêmes mais bon... 80 000 déploiements des produits B.I de la compagnie Jasper Soft, 20 000 développeurs ont accédé au portail BIRT Exchange et Pentaho Corp a réussi à obtenir un financement de 12 Millions $ (signe de bonne santé financière et de confiance des investisseurs).
- Le coté personnalisation plait beaucoup dans l'OSBI. En effet, il est très séduisant d'avoir un environnement ouvert qu'on peut adapter à sa guise. Mais tout à un prix ...
- Les solutions OSBI "reste intéressantes" selon les interviews de l'auteur. Les entreprises envisagent mais n'emboitent pas encore le pas. La première restriction est le faite que "Open Source ne veux pas dire gratuit !", en ce sens ou les couts amortis par l'acquisition des logiciels sont largement grignotés par le développement, la personnalisation et le support.
- Autre "piège" mentionné par l'auteur de cet excellent article : les frais cachés de l'OSBI !!! En effet, les versions en téléchargement libres de la suite B.I de Jasper (pour ne citer que cet exemple) contient les fonctionnalités de base de reporting et d'analyse. Dès que l'on veut quelque chose de plus "enterprise", il faut mettre la main au portefeuille et se procurer la licence pro : 25 000 $ pour une année de licence et de services pour Jasper, 30 000$ pour pentaho (selon les recherches de l'auteur)... ça donne à réfléchir ! Et ça pousse surtout à BIEN évaluer les besoins de l'entreprise avant de se lancer dans une aventure Open Source.

Le fait est, surtout avec la récession économique mondiale, que l'on se tourne de plus en plus vers les solutions B.I mais on reste craintif (à tort ou à raison). Parions que l'avenir sera Open Source

Imaginez toutes les bonnes pratiques de conception d'entrepôt de données, de conception et de réalisation d'ETL, de création de cubes et de reporting regroupés en un seul projet...
Et bien c'est ce que Microsoft a tenté de faire avec sont projet REAL. Le but affiché de ce projet est d'être une référence et une source de bonnes pratiques pour les entreprises décidant de partir de l'avant avec un environnement décisionnel à grande échelle. Je dis grande échelle car le projet cible les gros entrepôts de données avec des problématiques de stockage, de performances et bien sur de processus métier.
Cette initiative, toujours en cours de documentation est disponible à cette adresse : http://www.microsoft.com/sql/solutions/bi/projectreal.mspx
Un premier document que je viens de lire : Business Intelligence ETL Design Practices m'a beaucoup impressionné par la quantité de "best practices" et de "design patterns" qu'il explique. Autre truc qui m'a vraiment séduit, l'utilisation de Reporting Services pour monitorer les exécutions des ETL !!! Au lieu d'avoir des Logs contraignants, on met tout ça dans un rapport qui mis à jour quotidiennement. Fallait y penser !

On continue sur notre lancée avec le partitionnement sous Sql Server 2k5.
Qu'est ce que le partitionnement ?
Et bien c'est tout simplement le fait de diviser, physiquement, les données d'une table, d'une vue ou d'un index. La division se fait horizontalement (par lignes) et permet ainsi de diviser les grosses tables en petits morceaux mieux gérables.
Pourquoi partitionner ?
Imaginez que vous ayez une table de commandes qui recoit chaque jour des milliers de lignes, au fil des années, cette table commencera a devenir très grosse et très peu gérable (dans le cas ou vous voudriez ajouter un index, ou modifier une colonne, etc.). En fait, la table deviendra en définitif un gros bloc monolythique intouchable...
Pourquoi ne pas avoir la possibilité de diviser cette table entre plusieurs disques durs ? ainsi, nous pourrions mettre les commandes du mois dans un disque dur à faible capacité mais à très grande vitesse et les données "archives" dans un enorme disque de plusieurs centaines de Go. Pourquoi ne pas mettre une grosse table dans plein de petits disques durs ? Nous pourrions ainsi bénéficier de parallèlisme dans la lécture et l'ecriture des données.

C'est pour ces raisons que le partitionnement existe !

Le partitionnement sous Sql Server 2005
Le partitionnement se fait en trois phases :

1- Création d'une fonction de partitionnement : une fonction de partitionnement est totalement indépendante de toute structure physique ou logique de la table de données. Son rôle est de définir des "points de partitionnement" ou les valeurs qui délimitent les partitions. Voici la structure de cette fonction :
 
CREATE PARTITION FUNCTION partition_function_name ( input_parameter_type ) 
AS RANGE [ LEFT | RIGHT ] 
FOR VALUES ( [ boundary_value [ ,...n ] ] ) [ ; ] 

Un exemple :
 
create partition function maPartFonc (int) as range right for values (1000, 2000, 3000); 

cette fonction à comme paramètre un entier et dit : je partitionne des que l'entier que tu m'a spécifié atteint 1000, 2000 ou 3000.
La clause AS RANGE LEFT|RIGHT montre juste à quelle partition va aller le point de partitionnement.

2- Création d'un schéma de partitionnement : un schéma de partitionnement spécifie les zones de partitionnement physiques (alors que la fonction de partitionnement désigne les points logiques) et les associent à la fonction de partitionnement, ces zones de partitionnement sont en fait les filegroups qui composent votre base de données. (si vous ne savez pas ce qu'est un filegroup, consultez : http://msdn2.microsoft.com/en-us/library/ms176061.aspx)
La syntaxe pour créer un schéma de partitionnement est la suivante :
 
CREATE PARTITION SCHEME partition_scheme_name 
AS PARTITION partition_function_name 
TO ( { file_group_name | [ PRIMARY ] } [ ,...n ] )[ ; ] 

Un exemple :
 
create partition scheme partSchema as partition partFunc to ([FileGroup1],[FileGroup2],[FileGroup3]) 
go 

Cette commande effectue les opérations suivantes :
les données entre 0 et 1000 seront stockées dans [FileGroup1],
les données entre 1001 et 2000 seront stockées dans [FileGroup2],
les données entre 2001 et l'infini seront stockées dans [FileGroup3].
Si la proposition "les données entre x et y" n'est pas claire, c'est normal, c'est la troisième étape

3- Création de tables (index ou vues) partitionnées : dernière et ultime étape, nous allons comprendre pourquoi nous avons fait les étapes 1 et 2.
La syntaxe pour créer une table partitionnée est la suivante :
 
CREATE TABLE 
[ database_name . [ schema_name ] . | schema_name . ] table_name 
( { <column_definition> | <computed_column_definition> } 
[ <table_constraint> ] [ ,...n ] ) 
[ ON { partition_scheme_name ( partition_column_name ) | filegroup 
| "default" } ] 
[ { TEXTIMAGE_ON { filegroup | "default" } ] [ ; ] 

Un exemple :
 
create table MaTable ( 
PK int identity(1,1) primary key, 
Nom nvarchar(50), 
Prenom nvarchar(80) 
) 
on partSchema(PK) 
go 

Ce que nous venons de faire : créer une table toute bête et lui associer le shéma de partitionnement crée précédement avec la clé primaire (le int) comme paramètre de fonction de partitionnement. En clair : tous les enregistrement avec clé primaire inférieure ou égale à 1000 iront dans le FileGroup1, les enreg avec 1001 inf à PK et inf ou égl à 2000 dans FileGroup2, etc.

Imaginez juste ça à plus grande échelle avec des filegroups dans des disques séparés. Voila l'utilité du partitionnement !

SELECT sur des tables partitionnées
Autre truc sympa avec le partitionnement dans Sql Server 2005, c'est la possibilité de faire des requêtes sur des partitions !!! Vu que le partitionnement est un méchanisme tout à fait transparent pour les personnes utilisant les tables, il serait embêtant pour vous, DBA qui avez partitionné la table, de parcourir toute la table avec un SELECT en sachant pertinament que les données que vous cherchez sont dans une partition X.
Il est possible de cibler une partition (ou plusieurs) dans votre SELECT grace à l'instruction $PARTITION. Exemple :
SELECT * FROM MaTable WHERE $PARTITION.ma_fonction_de_partition(cle) = 3
Cette instruction nous retourne tous les enregistrements de la partition numéro 3. Sympa non !
Mais attendez une minute !!!! Comment connaitre le numéro de la partition ??? Et bien c'est tout simple, la requête suivante vous donne tous les numéros de partition de votre table :
 
SELECT $partition.partfunc(id) AS [numeroPart], count(*) [nombre de lignes] 
FROM MaTable GROUP BY $partition.partfunc(id) 

de plus, cette requête nous permet d'avoir le numéro de partition ou est stocké l'enregistrement avec PK = 1234 :
 
SELECT $partition.ma_fonction_de_partition(4000) as [numero partition]; 


Voila voila ! Avec ça, vous devriez être blindés !