Un Cube, qu'est ce que c'est ?

Le 04/10/2011, helios a supposé :

simplement que SQL ne sait pas gerer plus de deux dimensions donc incapable
de gere ton cube puisque 3 dimensions

etant donné qu'il existe au moins une bijection entre N (ensemble des
entiers naturels) et Nx (n-uplets de x entiers naturels), cette
affirmation est mathématiquement fausse.

helios avait prétendu :

UNE
table SQL il faut que n, m, et P soit 0 ou 1 (deux valeurs)

Pourquoi une seule table ? Au dela vous avez du mal à suivre ?

LOL

Pif 34 a écrit le 04/10/2011 à 19h00 :

puis-je moi aussi poser la question d'ou tu veux en venir ?

que tu utilise un cube ou pas, tout le monde s'en moque, et toi aussi
normalement (c'est pas agressif, c'est provocateur). Qu'importe le nom...

TCD c'est une fonction excel et peut etre access... on quitte le monde
de la base de donnée relationnelle car il ne s'agit pas d'un
opérateur
relationnel a proprement parler.

Un cume, un espace multidimensionnel, des composantes multimodales, tu
peux donner des nom, c'est pas le plus important..

Un cube ca induit plusieurs choses comme le fait justement remarque Yliur:
1) un outillage générique adapté à de gros volume
(datawarehouse,
datamart), des outils d'ETL, des outils d'analyse et de visu, etc.
2 (le plus important) l'usage : un (hyper)cube c'est un espace
muldimensionnel pour lequel on veut extraire et analyser une ou
plusieurs dimensions. Une dimension, c'est simple et pas besoin d'outil.
Plus de 2 dimensions, c'est complexe à visualiser et analyser en
général, ca implique des outils d'analyse de données et de
visu d'info
fouillé et adapté au domaine. Reste les 2D: on va extraire un
plan dans
ton espace qu'on va analyser. Ce que te permet le cube, c'est de choisir
indifférement 2 dimensions et de pouvoir les comparer...

un datadube, en relationnel c'est quoi ?
deux entités:
- entité "dimension"
- entité "point"

et une relation n-n entre les deux, avec un attribut "valeur" qui
donc
permet d'associer à chaque point dans chaque dimension une valeur.


et sortir un plan, c'est projeter sur un plan en Y une dimension et en X
une autre... c'est tout

sortir 3D ou plus, c'est facile aussi... c'est analyser qui est sur...

On peut biensur enrober sur ce pattern, mais un datacube, c'est ni plus
ni moins que ca...

Donc le datacube, c'est un mot qui t'intéresse quand tu veux vendre ou
acheter un produit par rapport à une catégorie de distribution de
software pasque t'auras le Oracle Grid, le oracle cube par exemple etc.
avec son lot d'outillage et le prix qui va bien..

Ce qui me semble intéressant, c'est pas tant de produire un datacube que
de produires les outils pertinent pour l'utilisateur final... car ce qui
est proposé est le plus souvent assez pipo et inutilisable... y'a plein
d'outils matheux mal compris et mal utilisé, et aucun outils visuel...

bonsoir Pif34
merci pour ton éclairage.

tu me demandes où je veux en venir ? simplement comprendre ce concept qui fait couler bcp d'encre et qui suscite n définitions. Je vois comme il est difficile d'expliquer ce que c'est.
Toi même tu dis qu'un cube est un espace multi-dimensionnel (plusieurs dimensions) dans lequel on veut analyser une ou pls dimensions.

plus bas tu parles d'"entités", et tu dis qu'un datacube, c'est 2 entités et une relation n-n entre les 2 (que je comprends comme des "mesures"). Et là, tu dis qu'un datacube, c'est une dimension et un point (on n'est plus dans le multidimensionnel et ce que tu décris ressemble à un 2D : un axe, une dimension, des mesures.

j'ai compris qu'il s'agit d'un univers de travail qui doit permettre de charger de larges volumes de données, qui doit être en mesure de recalculer en des temps records, et qui doit donner des clés de lecture aux opérationnels métier.
J'ai aussi compris que les données doivent être analysées par un système de gestion de bases de données de type XML qui doit permettre l'analyse en 3D.

C'est certainement encore plus complexe que ça, mais à mon niveau (je ne suis pas une informaticienne), j'ai perçu cette complexité dans toutes vos tentatives de définition.

super Hélios, je commence à percevoir la nature du cube : on est bien dans
l'univers de la BDD et non plus dans sa représentation.

est ce que ça signifie que je dois définir en amont les axes d'analyse, les
dimensions et les mesures afin que le SGBDM les prévoit ou est ce que j'ai, en
tant qu'utilisateur final, la possibilité de définir des dimensions et des axes
en live ?

un peu des deux :

il faut definir la structure de ta base au départ afin d'eviter de faire
du rustinage a tout va et avoir une base de donnée qui soit un minimun
structuré
mais tu peux rajouter des dimensions et des data apres coup

c'est un peut comme si tu dessinais un arbre tu dessine le tronc, les
branches principales et plusieurs niveau de branches secondaires
mais apres tu peux rajouter des branches des "branchettes" et meme des
feuilles

Autre question : si c'est le SGBDM qui fabrique le cube, à quoi servent alors
les outils de BI tels que Saas, R, XnView et autres ... ?

c'est des outils de visualisations

merci pour vos lumières !!

Pif 34 a écrit :

puis-je moi aussi poser la question d'ou tu veux en venir ?

que tu utilise un cube ou pas, tout le monde s'en moque, et toi aussi
normalement (c'est pas agressif, c'est provocateur). Qu'importe le nom...

TCD c'est une fonction excel et peut etre access... on quitte le monde
de la base de donnée relationnelle car il ne s'agit pas d'un opérateur
relationnel a proprement parler.

Un cume, un espace multidimensionnel, des composantes multimodales, tu
peux donner des nom, c'est pas le plus important..

Un cube ca induit plusieurs choses comme le fait justement remarque
Yliur:
1) un outillage générique adapté à de gros volume (datawarehouse,
datamart), des outils d'ETL, des outils d'analyse et de visu, etc.
2 (le plus important) l'usage : un (hyper)cube c'est un espace
muldimensionnel pour lequel on veut extraire et analyser une ou
plusieurs dimensions. Une dimension, c'est simple et pas besoin
d'outil. Plus de 2 dimensions, c'est complexe à visualiser et analyser
en général, ca implique des outils d'analyse de données et de visu
d'info fouillé et adapté au domaine. Reste les 2D: on va extraire un
plan dans ton espace qu'on va analyser. Ce que te permet le cube,
c'est de choisir indifférement 2 dimensions et de pouvoir les comparer...

un datadube, en relationnel c'est quoi ?
deux entités:
- entité "dimension"
- entité "point"

et une relation n-n entre les deux, avec un attribut "valeur" qui donc
permet d'associer à chaque point dans chaque dimension une valeur.


et sortir un plan, c'est projeter sur un plan en Y une dimension et en
X une autre... c'est tout

sortir 3D ou plus, c'est facile aussi... c'est analyser qui est sur...

On peut biensur enrober sur ce pattern, mais un datacube, c'est ni
plus ni moins que ca...

Donc le datacube, c'est un mot qui t'intéresse quand tu veux vendre ou
acheter un produit par rapport à une catégorie de distribution de
software pasque t'auras le Oracle Grid, le oracle cube par exemple
etc. avec son lot d'outillage et le prix qui va bien..

Ce qui me semble intéressant, c'est pas tant de produire un datacube
que de produires les outils pertinent pour l'utilisateur final... car
ce qui est proposé est le plus souvent assez pipo et inutilisable...
y'a plein d'outils matheux mal compris et mal utilisé, et aucun outils
visuel...

en resumé avant de vouloir utilisé une technologie de cube hypercube
.... il faut d'abord savoir quel type de resultat et analyse on veux
obtenir et sous quel forme on veux les visaulisé
apres la solution va du bricolage sous SQL au SGBD gérant des multi
niveau de données (XML, MD, MV )

Alain Montfranc a écrit :

helios a écrit :

Alain Montfranc a écrit :

helios a présenté l'énoncé suivant :

Alain Montfranc a écrit :

helios avait quoté comme un goret asthmatique en rut le 03/10/2011 :

XML qui fait du multiniveaux par balise (ce qui explique que les
moulinettes XML-SQL soit du pipeau

<TROLL>

Encore une affirmation gratuite (et fausse)

aussi faux que la "perpective cavaliere" represente un volume sur
une feuille de papier d'ailleurs la perpective cavaliere est
tellement parfaite que les camera en 3D n'existent pas et les
hologrammes non plus

Comparaison n'est pas raison

d'ailleurs l'artifice "perpective cavaliere" ne permet pas de
representer un hypercube

on s'en fout

XML est multi niveau de donnés SQL à 2 niveaux de donnée
(plan) alors demontre moi que tu peut representer par exemple un
objet a 10 dimensions sur une feuille de papier exemple dessinne
sur un format A4 un objet ayant les dimensions Q R S T U V W X Y
Z de 30 mm

Aucun rapport

puisques Alain Montfranc le dit la réalité est comme cela, malgrés
que sa moulinette n'a pas ete capable de convertir une table XML que
j'avais fournis (127 balises imbriqué) la comparaison objet
multidimesinnel feuille est juste et demontre bien que une table SQL
ne peux pas etre l'equivalent d'une table XML si celle ci a un nombre
de balises imbriqué suffisament grand

Dans tes reves. Ma moulinette marche tres bien ;-)

mais n'a pas fonctionné sur le fichier XML que j'avais envoyé et depuis
qu'elle marche elle doit etre loin de la réalité :-)

Alain Montfranc a peut etre des interets a pretendre le contraire
style vente a des gogos de sa moulinette

Je ne vends rien. Contrairement à d'autres

moi non plus je ne vends rien contraire a un certain Fred (pas de
livre, .......) je suis un prestataire de services

</TROLL>

Alain Montfranc a écrit :

helios avait prétendu :

UNE table SQL il faut que n, m, et P soit 0 ou 1 (deux valeurs)

Pourquoi une seule table ? Au dela vous avez du mal à suivre ?

LOL

parce que gerer 127 niveau (theorique) de donnée donne 2^127 jointures
et tables

Alain Montfranc a écrit :

helios avait prétendu :

UNE table SQL il faut que n, m, et P soit 0 ou 1 (deux valeurs)

Pourquoi une seule table ? Au dela vous avez du mal à suivre ?

LOL

parce que combien de tables et jointures SQL il faudrait pour remplacer
une table MV de

2^15 attributs contenant
2^15 valeurs contenant
2^15 sous-valeurs contenant
2^15 sous sous valeurs contenant
2^15 sous sous sous valeurs contenant
2^15 sous sous sous sous valeurs contenant
2^15 sous sous sous sous sous valeurs contenant
2^15 sous sous sous sous sous sous valeurs contenant
2^15 sous sous sous sous sous sous sous valeurs contenant
2^15 sous sous sous sous sous sous sous sous valeurs

et je me suis arreter a 10 niveaux alors que la norme en prevois jusque
127 et le 2^15 est le nombre d'entité que peut contenir un niveau

helios a écrit le 05/10/2011 à 07h01 :

Pif 34 a écrit :

puis-je moi aussi poser la question d'ou tu veux en venir ?

que tu utilise un cube ou pas, tout le monde s'en moque, et toi aussi
normalement (c'est pas agressif, c'est provocateur). Qu'importe le nom...

TCD c'est une fonction excel et peut etre access... on quitte le monde
de la base de donnée relationnelle car il ne s'agit pas d'un
opérateur
relationnel a proprement parler.

Un cume, un espace multidimensionnel, des composantes multimodales, tu
peux donner des nom, c'est pas le plus important..

Un cube ca induit plusieurs choses comme le fait justement remarque
Yliur:
1) un outillage générique adapté à de gros volume
(datawarehouse,
datamart), des outils d'ETL, des outils d'analyse et de visu, etc.
2 (le plus important) l'usage : un (hyper)cube c'est un espace
muldimensionnel pour lequel on veut extraire et analyser une ou
plusieurs dimensions. Une dimension, c'est simple et pas besoin
d'outil. Plus de 2 dimensions, c'est complexe à visualiser et analyser
en général, ca implique des outils d'analyse de données
et de visu
d'info fouillé et adapté au domaine. Reste les 2D: on va
extraire un
plan dans ton espace qu'on va analyser. Ce que te permet le cube,
c'est de choisir indifférement 2 dimensions et de pouvoir les
comparer...

un datadube, en relationnel c'est quoi ?
deux entités:
- entité "dimension"
- entité "point"

et une relation n-n entre les deux, avec un attribut "valeur" qui
donc
permet d'associer à chaque point dans chaque dimension une valeur.


et sortir un plan, c'est projeter sur un plan en Y une dimension et en
X une autre... c'est tout

sortir 3D ou plus, c'est facile aussi... c'est analyser qui est sur...

On peut biensur enrober sur ce pattern, mais un datacube, c'est ni
plus ni moins que ca...

Donc le datacube, c'est un mot qui t'intéresse quand tu veux vendre ou
acheter un produit par rapport à une catégorie de distribution
de
software pasque t'auras le Oracle Grid, le oracle cube par exemple
etc. avec son lot d'outillage et le prix qui va bien..

Ce qui me semble intéressant, c'est pas tant de produire un datacube
que de produires les outils pertinent pour l'utilisateur final... car
ce qui est proposé est le plus souvent assez pipo et inutilisable...
y'a plein d'outils matheux mal compris et mal utilisé, et aucun outils
visuel...

en resumé avant de vouloir utilisé une technologie de cube
hypercube
.... il faut d'abord savoir quel type de resultat et analyse on veux
obtenir et sous quel forme on veux les visaulisé
apres la solution va du bricolage sous SQL au SGBD gérant des multi
niveau de données (XML, MD, MV )

bonjour Hélios,

peux tu définir exactement ce qu'est une dimension ?
dans les définitions que j'ai lues, le temps par ex est une dimension ; les produits d'un magasin sont un axe d'analyse et les pays dans lesquels les magasins sont installés sont aussi un axe d'analyse.
es tu d'accord avec ça, déjà ?

Ce qui me gène dans cette vision, c'est qu'on dit qu'une fonction propre au cube est de pouvoir faire pivoter les axes d'analyses et les dimensions afin de donner une autre lecture des données. J'en conclus donc qu'une dimension peut devenir un axe d'analyse et inversement.

Ca m'amène à ma seconde question :
pourquoi avoir besoin de définir en amont des "dimensions" ? Pourquoi ne pas simplement demander de définir des typologies de données que l'on choisira de mettre en dimension ou en axe lors de la construction du cube ?

merci encore

thanksforyourhelp wrote:

Pif 34 a écrit le 04/10/2011 à 19h00 :
merci pour ton éclairage.

de nada

tu me demandes où je veux en venir ? simplement comprendre ce concept qui fait
couler bcp d'encre et qui suscite n définitions. Je vois comme il est difficile
d'expliquer ce que c'est.

pas tant que ca a mon sens: un cube c'est terme marketing pour des
gammes de produit, comme tu dirais ETL ou backbone ou ERP... tu peux
mettre tout et n'importe quoi...

Toi même tu dis qu'un cube est un espace multi-dimensionnel (plusieurs
dimensions) dans lequel on veut analyser une ou pls dimensions.

oui, espace multidimensionnel est synonyme de espace vectoriel

plus bas tu parles d'"entités", et tu dis qu'un datacube, c'est 2 entités et
une relation n-n entre les 2 (que je comprends comme des "mesures").

oui, je parle de la modélisation relationnelle: si tu fais un schéma
"entité-association", t'as 2 entité est une association, l'association a
un attribut... si je te fais un modèle relationnel:
- Dimension (id, libelle)
- Point (id, libelle)
- Valeur (idDimension_FK, idPoint_FK, valeur).


Et là, tu

dis qu'un datacube, c'est une dimension et un point (on n'est plus dans le
multidimensionnel et ce que tu décris ressemble à un 2D : un axe, une dimension,
des mesures.

non, je dis que l'usage d'un datacube va consister à extraire un sous
ensemble des dimensions, le plus souvent 2... Par définition, un espace
à 1 dimension est un espace vectoriel, comme un ensemble vide reste un
ensemble..

donc dans ton datacube tu va extraire deux dimensions et regarder si tu
as une correlation entre les points (par exemple, telle catégorie de
revue est plutot lue par des femmes, etc.). Depuis longtemps il existe
des outils projeter plusieurs dimensions dans un plan et voir la
correction (ACP, ACM, MDS, etc.).

j'ai compris qu'il s'agit d'un univers de travail qui doit permettre de charger
de larges volumes de données, qui doit être en mesure de recalculer en des temps
records, et qui doit donner des clés de lecture aux opérationnels métier.

oui, ca induit une grosse volumétrie et donc des problématique de
performance, comme un datawarehouse.

J'ai aussi compris que les données doivent être analysées par un système de
gestion de bases de données de type XML qui doit permettre l'analyse en 3D.

non, pas obligatoire du XML, c'est lourd et verbeux... si tu fais du
Oracle, tu reste en pure relationnel, c'est plus performant...

pour la 3D, c'est le visualisation de la donnée, ca n'a rien a voir...
si t'as que 2 dimensions a projeter, tu mets surtout pas de la 3D...et
si t'as plus de 3 dimensions, t'es obligé de recourir des outils
mathématiques... la 3D, c'est sans intéret, meme pour 3dimensions à mon
avis...

C'est certainement encore plus complexe que ça, mais à mon niveau (je ne suis
pas une informaticienne), j'ai perçu cette complexité dans toutes vos tentatives
de définition.

j'ai essayé de montrer la simplicité via une définition simple: un
hypercube, c'est des points dans un espace vectoriel et ca se modélise
dans 3 tables dans l'absolu... et on l'utilise en extrayant une partie
des dimensions, d'ou un outillage un peu particulier...

après, ca inclue tout un tas de problématique: performance, volumétrie,
structuration, analyse de donnée, IHM et visualisation d'information, et
tous les besoins markettings et utilisateur divers en aval, etc.