Conseil 38: qu'est ce qu'une application analytique

Il y a de nombreuses discussions sur la nouvelle "coqueluche" de la communauté décisionnelle ... les applications analytiques. Les applications analytiques promettent de livrer une nouvelle valeur métier pour les organisations qui ont déjà fait d'importants investissements dans leur infrastructure et leurs compétences en matière d'entrepôt de données. Mais qu'entendons-nous quand nous disons "application analytique"? Et quelles sont les évolutions récentes dans l'industrie qui ont conduit à tout ce battage sur les applications analytiques?

Conseil 37: Modéliser le suivi d'un processus à l'aide d'une table de fait de type instantané cumulé

Rappelez-vous qu'une table de faits est un endroit où nous stockons des mesures émanant d'un processus métier particulier. Les tables de dimension entourent et décrivent ces mesures.

Rappelez-vous aussi que le grain d'une table de fait est la définition exacte de ce qu'un enregistrement d'un fait représente. Il est certainement vrai que la clé d'une table de fait définit le grain, mais souvent la déclaration la plus claire du grain est un concept métier plutôt qu'une liste technique de clés étrangères. Par exemple, le grain d'une table de fait représentant un processus de prise de commande peut être "la ligne d'un produit sur une commande", alors que la définition technique de la clé de cette table peut être "numéro de facture par produit par promotion".

Conseil 36: Etre ou ne pas être (centralisé)

Contrairement à William Shakespeare et certains experts de l'industrie des entrepôts de données, ce n'est pas la question.


Dans cet article, nous discutons d'un problème rencontré dans les environnements d'entrepôts de données et de data-marts matures. Alors que certaines organisations sont des nouveaux venus dans cet univers, d'autres sont là depuis un certain temps. Et bien que le marché arrive à maturité, la cause de souffrances que provoque les entrepôt des données au sein des organisations IT est liée à son évolution. Récemment, la centralisation a été promue comme le dernier élixir miracle. La centralisation est revendiquée pour transformer les data-marts indépendants et hétérogènes en "or", en réduisant les coûts d'administration et en améliorant la performance. Alors que la centralisation "peut" offrir une certaine efficacité opérationnelle, elle ne traite pas en soi les grandes questions d'intégration et de cohérence.

Conseil 35: Modéliser les intervalles de temps

Au cours des deux dernières années, j'ai vu une augmentation de la demande pour les applications qui ont besoin de poser des questions sur des intervalles de temps. Une personne a le fait quand il dit: "chaque enregistrement dans ma table de fait est un épisode de valeur constante dans un laps de temps". Un intervalle de temps peut démarrer et s'arrêter à des points arbitraires dans le temps. Dans certains cas, des intervalles de temps peuvent être liés pour former une chaîne ininterrompue, dans d'autres cas, ils sont isolés, et dans le pire des cas, ils se chevauchent arbitrairement. Mais chaque intervalle de temps est représenté dans la base de données par un seul enregistrement. Pour faciliter la visualisation de ces variations, imaginons que nous avons une base de données remplie de transactions atomiques, comme les dépôts et les retraits de comptes bancaires. Nous incluons également les transactions d'ouverture et de fermeture de compte. Chaque transaction définit implicitement un épisode de valeur constante dans un intervalle dans le temps. Un dépôt ou un retrait définit une nouvelle valeur pour le solde du compte qui est valable jusqu'à la prochaine transaction. Ce laps de temps pourrait être une seconde ou plusieurs mois. La transaction d'ouverture de compte définit le statut du compte comme actif en permanence sur un laps de temps jusqu'à ce qu'une transaction de fermeture de compte apparaisse.

Conseil 34: Vous n'avez pas besoin d'entrepôt de données d'entreprise

Un "entrepôt de données d'entreprise" (EDW pour Enterprise Data Warehouse) est le nom d'une approche de conception. L'architecture EDW diffère sensiblement de celle du bus décisionnel. L'EDW incarne un certain nombre de thèmes connexes qui doivent être mis en comparaison avec l'approche du bus décisionnel. Il peut être utile de séparer les questions logiques des questions physiques pour le moment.

Logiquement, les deux approches préconisent un ensemble cohérent de définitions qui rationalisent les différentes sources de données dispersées dans l'organisation. Dans le cas du bus, les définitions importantes concernent principalement les dimensions conformes et les faits conformes. Avec l'approche EDW, la cohérence semble beaucoup plus amorphe. Cela repose sur le fait que si vous avez un modèle Entité/Relation hautement normalisé unique de toutes les informations de l'entreprise, vous savez alors comment administrer des centaines ou des milliers de tables de manière cohérente. Mais, dépassant ce manque de précision, on pourrait soutenir que les deux approches sont du même avis jusqu'ici. Les deux approches visent à appliquer des règles cohérences pour unifier toutes les sources de données distribuées.