Projet IDAPA

Accueil > Bases de données relationnelles et indexation du contenu > Rapport - Partie 2a

Rapport - Partie 2a

Etude des besoins

vendredi 6 février 2009, par Yoann Moreau

3. Etude des besoins de la partie OLAP et MySQL

Le domaine d’aide à la décision est un domaine large qui peut s’appliquer à de nombreux contextes d’activité. Un entrepôt de données a pour but de stocker un maximum d’informations, celles ci sont donc très variées et regrouper ces informations nécessite une certaine mise en forme. L’utilisation de ces informations par la suite peut également être variée, dans les outils d’aide à la décision, des tableaux de bord présentent une multitude d’indications comme des regroupements de valeurs (moyenne, somme etc) et des recoupements plus complexes selon
différents axes de valeurs (moyenne par rapport au temps et regroupée par régions par exemple).

Les possibilités d’utilisation de ces données sont très variables et nécessitent donc des outils souples pour y accéder. Deux opérations principales ont été retenues dans la sélection de sous ensembles de données (voir ci dessous), ces opérations peuvent se combiner entre elles. Dans la pratique les calculs de scoring font de nombreux calculs matriciels qui peuvent être facilement réalisés en SQL sur des tables classiques, ces calculs pourraient donc être effectués directement par la partie OLAP et seront à définir par la partie scoring.

On distinguera deux utilisations de l’entrepôt de données, l’administration qui ne fait
qu’ajouter des données dans l’entrepôt sans jamais les modifier (les données d’un entrepôt sont figées) et la restitution qui ne fait qu’y lire des informations. La restitution doit permettre d’obtenir les données selon des requêtes précises ne concernant que certaines parties de l’entrepôt, les critères doivent couvrir des besoins variables et donc être très adaptables. En fait l’entrepôt effectuera même certains traitements sur ces données pour faciliter les calculs de la partie scoring.

3.1 Diagramme des cas d’utilisation

Voir document pdf ci-joint.
Ces cas d’utilisation seront détaillés par la suite.

3.2 Conventions de nommage

Afin de clarifier les propos techniques par la suite, il a été décidé certaines conventions en ce qui concerne le nommage d’éléments ou d’actions.

valeur : Information sous forme de texte de taille variable et non limitée correspondant aux données effectives, elle est unique pour un id et un attribut donné (et donc associée à eux).

attribut:Descriptif de données, sous forme de texte de taille variable mais limitée, il donne la signification d’une valeur.

id:Identifiant unique correspondant à un groupe de valeurs liées (e.g. un n° de dossier).

valeur nulle:Valeur n’existant pas pour un id donné.

cube : Ensemble des valeurs, attributs, et id de l’entrepôt de données.

sous cube projeté:Sous ensemble d’un cube ne contenant que certains attributs donnés et leurs valeurs associées.

sous cube coupé : Sous ensemble d’un cube ne contenant que certains id donnés et leurs valeurs associées.

3.3 Fonctionnalités de la partie OLAP et MySQL

3.3.1 L’administration

L’ajout de données dans le cube a pour sources des tables relationnelles classiques, il
faudra lister les attributs par leur nom puis ajouter les valeurs de la table ligne par ligne (pour associer l’id aux valeurs) et valeur par valeur (pour associer chaque valeur à l’attribut de sa colonne).

Entrée : une table avec une clé primaire unique, un nombre de colonnes et lignes illimité.
Sortie : aucune. L’entrepôt contient les données ajoutées.

3.3.2 La restitution : La projection

La projection doit créer un sous cube en « nettoyant » les lignes d’attributs non voulus.
Pour cela on utilise une autre table contenant la liste des attributs et un indicateur précisant si l’attribut veut être conservé ou non dans la projection. Toutes les valeurs associées aux attributs non choisis seront éliminées. Bien sûr les données du cube ne sont en aucun cas modifiées ou supprimées, la projection crée un autre cube où elle copie uniquement les données choisies. Lors de cette opération, on peut également convertir les valeurs en types standards, selon l’indication donnée par l’attribut, on utilisera pour cela une table de correspondances.

Entrée : la liste des attributs à conserver, et éventuellement les correspondances attribut/type.

Sortie : un sous cube projeté.

3.3.3 La restitution : La coupe

La coupe doit créer un sous cube en ne sélectionnant que les valeurs associées à des id
répondant à certains critères. Les critères peuvent s’appliquer sur n’importe(s) quel(s) attribut(s) associé(s) à un id. Il faudra préciser le choix à faire lorsqu’un critère s’applique sur un attribut qui n’a pas de valeur (l’attribut et la valeur n’existent donc pas pour l’id testé), soit cette valeur nulle équivaut à une condition vraie, soit à une condition fausse.

Entrée : des couples attribut/valeur faisant office de condition, éventuellement le résultat de chaque condition pour les valeurs n’existant pas.
Sortie : un sous cube coupé.