bdmd diamant

I Introduction

Rappel des concepts

Base de connaissances

N-arbre Fractal Virtuel

Flocon 3D push pull

Stockage en étoile

II Décision

Faire 60 fichiers sam

Faire 60 tables db2

Faire 60 LOAD

Concaténer les 60 tables db2 en une table diamant

III Explication

3 applications

Deux périodes

10 tables équifolios

IV Gestion du versionning (états de livraison)

Statut

Etat de livraison

Date de l'état de livraison

Date de saisie du statut

V principes d'utilisation

SWEET SPOT

PAM = diamant, or, argent, cailloux, détail

principe de classification et segmentation d'un datawarehouse en vue du data mining

Datamining

Diamant

Etoile

Branche d'une étoile

Dimensions

Hypercube

Axe

Changer de dimension

Dimensions traditionnelles

VI description du systeme

L'analyse est multidimensionnelle :

Le stockage est en étoile

La navigation

Il y a un diamant au centre de la BDMD

Autour du diamant dans le plan vertical il y a une étoile PULL

Autour du diamant, dans le plan horizontal il y a un flocon PUSH

BTI

SGBDR

systèmes à base d'arbres, SGBDOO

HYPER QUERY

le flocon

le NFV appartient à une BC (base de connaissances multimédia) gérée par un SGBCE

VII Exploitation

Taches à faire à la fin de PROJETRIM1 pour bien commencer PROJETRIM2

Gestion des composants pour PROJETRIM2

I Introduction

Rappel des concepts

Il y a une base de connaissances

C'est un N-arbre Fractal Virtuel

Le N-arbre Fractal Virtuel a un 2-arbre

le 1er arbre s'appelle: décomposition en analyse, programmation, mise en oeuvre

le 2ème arbre s'appelle: donnez moi tout ce qui concerne tel sujet

A l'intérieur de l'arbre "décomposition en analyse, programmation, mise en oeuvre"

il y a la branche analyse

Dans la branche analyse il y a l'Hyper Monde Virtuel à 10 niveaux

Dans la branche programmation il y a entre autres les queries

Dans la branche queries il y a un 4-arbres

Le 4-arbres référencant les queries contient:

l'arbre de décomposition par folios

l'arbre de décomposition par tâches

l'arbre de décomposition par niveaux de consolidation

l'arbre de décomposition par la dimension temps

Le 2-arbre contient un 4-arbre c'est pour celà que ce n-arbre est fractal.

2 branches d'un même arbre pointent vers 2 objets stockés différents

2 arbres d'un même n-arbre pointent vers le même objet stocké

là est la différence entre les branches d'un arbre et les arbres d'un n_arbre.

Chacun des 4 arbres référencant les queries pointe vers n feuilles

Chaque feuille est une liste

L'existance d'une liste permet à la vue de haut de s'arrêter assez tôt à un niveau assez synthétique

et de ne pas s'enfoncer dans la jungle des détails des niveaux bas

La feuille-liste est le niveau le plus bas de la partie non virtuelle (la partie directe) de l'arbre

Au delà de la partie directe non virtuelle de l'arbre, se trouve un lien virtuel (un pointeur dynamique

vers le lieu de stockage réel.

Le lieu de stockage réel stocke l'information

L'information qui concerne les queries existe sous forme description de query

(sous forme WORD), ou sous forme donnée dans une table DB2 BDMD (diamant) ou sous forme

listing de query.

D'autre part pour les non queries on peut avoir des formes dessins 2D ou 3D selon

le sujet ou bien des dossiers physiques sur papier.

Notre sujet est la BDMD

La BDMD est composée d'un diamant et d'une étoile autour du diamant

Le diamant est le coeur de l'étoile

Chaque branche de l'étoile est une dimension

Une dimension (ou axe) peut avoir des niveaux de totalisations (dynamiques ou précalculées)

La précalculation augmente la taille de la base

La précalculation augmente la vitesse d'extraction des sous-totaux

La floconisation diminue la taille de la base

Floconniser consiste à remplacer PROJETRIM1 par 1, et Folio 1 par 1, oui par 1, non par 0, décembre par c etc..

Une branche d'une étoile est une ligne droite

Une branche d'un flocon est une arborescence

Voilà la différence entre une branche d'une étoile et une branche d'un flocon

tous les chemins de l'étoile mènent au diamant sans carrefour

une branche d'un flocon peut déboucher sur un autre flocon de façon fractale

La BDMD = diamant + étoile autour du diamant est représentée dans le plan vertical

Le N-arbre queries = diamant + flocon autour du diamant est représenté dans le plan horizontal

La partie non virtuelle du flocon va de la racine des arbres jusqu'aux feuilles des arbres (feuille=liste)

La partie virtuelle du flocon est composée des pointeurs vers le diamant (coeur du BDMD = hypercube)

La partie stockage réel du flocon est le diamant contenant toutes les dimensions sous forme concentrée

Diamant = concentré = dur = valeur maximale, graphite = friable = valeur diluée

L'étoile (dans le plan vertical, BDMD hiérarchique à n dimensions)

+ le flocon (dans le plan horizontal, n-arbre fractal virtuel pour les queries )

= le flocon 3D push pull

3D = plan vertical + plan horizontal = flocon horizontal + étoile verticale

Push = type de requête prévue + structure préfabriqué + l'utilisateur choisit son chemin parmi

les chemins déjà préparés pour lui avec les requêtes et pointeurs déjà toutes prêtes

c'est à dire les réponses sont déjà toutes prémâchées

pull = permet à l'utilisateur de se fabriquer lui même des requêtes ad hoc en naviguant rapidement facilement

à travers toutes les dimensions possibles, sur tous les niveaux possibles de détail ou d'abstraction au sein de

chaque dimension ou axe.

SWEET SPOT: la combinaison entre 36 dimensions et 10 possibilités par dimension amène à conclure

sur l'existence de 10 à la puissance 36 cas possibles à mettre à la disposition de l'utilisateur qui consulte la base

pour conduire son analyse.

Cette possibilité nécessaire représente beaucoup de papier si on l'imprime et beaucoup

d'espace disque si on le stocke normalement.

Par contre

* si on fait un stockage en étoile (tous les cas possibles dans chaque dimension se trouvent autour et pas au milieu),

- si on floconnise en rejetant le maximum de détails hors du centre

-et si on ne met au milieu que les métadonnées (les plus précieuses, les données sur les données, les données

qui peuvent aiguiller sur d'autres données)

* alors la jointure entre les méta données(métadata)

et les données peut se faire dynamiquement à la volée (on the fly)

- ainsi le stockage est peu volumineux,

- les liens (du diamant aux branches de l'étoile) (ou des feuilles du flocon vers le diamant) dynamiques

sont faits après que la question est formulée,

- les requêtes à partir de plusieurs critères peuvent être construites selon le besoin du moment

(requêtes AD HOC, PULL)

- la BDMD est à la fois souple, puissante, riche, peu volumineuse, rapide, directe, multidimensionnelle,

hiérarchique et permet la navigation avec le maximum de fluidité.

- fluidité = pouvoir aller dans tous les sens facilement vers le haut (DRILL UP) , vers le bas (DRILL DOWN),

vers le côté (DRILL THROUGH), et aussi DRILL ACROSS(d'une dimension à l'autre),

DRILL OUT (vers WORD et VISIO) , DRILL DOWN TO DETAIL (vers les listings en entier).

- et notamment pouvoir combiner les dimensions

comme donnez moi toutes les queries de lecture du folio 1 de niveau siège du PROJETRIM 1 97

II Décision

Faire 60 fichiers sam

Faire 60 tables db2

Faire 60 LOAD

Concaténer les 60 tables db2 en une table diamant

III Explication

3 applications:

projetrim1

projetrim2

projmois

60 / 3 = 20 tables par application

Deux périodes:

ancienne

et prochaine

20 / 2 = 10 tables

Les 10 tables sont des équifolios

1 bdr

2 folio 1

3 folio 2

4 folio 3

5 folio 4

6 folio 5

7 folio 6

8 folio b

9 maj bdr, maj p60

10 sidg

IV Gestion du versionning (états de livraison)

Statut

colonne colonne

ancien prochain signification

1 0 = ancien non reconduit

1 1 = existant reconduit

0 1 = nouveau

0 0 = déjà désactivé en cti

Etat de livraison sur 2 à 3 car

DV = en développement = se trouve dans l'environnement de développement

VR = en vérification = en cours de recette technique = mis dans l'environnement de recette technique

= développement unitaire terminé

= mis dans la bibliothèque de communication qui va du développeur au recetteur technique

VL = en validation = en cours de recette fonctionnelle = vérification technique terminée

= mis dans prochain trim ou mois qui est l'image de ce que va contenir le CTI

au prochain trim ou mois

VT = validation terminée = mis dans prêt à livrer = en attente de livraison par lot c'est à dire

en attente que les autres composants soient prêts et en attente de laisser

libre la bibliothèque de départ de livraison pour d'autres choses (périodes de composants)

comme le réel qui tourne et qui doit être maintenu.

LV = livré mais pas encore vérifié arrivé = l'acte de livraison est fait

= se trouve dans derniers livrés

XP = en expé = l'expé a commencé mais n'est pas encore terminé

XT = expé terminé mais géné n'a pas encore commencé

EG = en géné = la géné a commencé mais n'a pas encore été validée

GT = géné terminée ==> doit se trouver dans image et dans la bibliothèque reflet de la géné de cette période.

DB = en debugging

DA = désactivé ne tourne plus en cti

PR = provisoire, à modifier après

OK = tourne en CTI

Date de l'état de livraison = j m aa

Date de saisie: m = mois

t = trim

aa = année

désigne aussi la date du statut

statut 0 0 0 déjà désactivé en CTI

statut 0 0 1 nouveau

statut 1 0 0 ancien non reconduit

statut 1 1 1 existant modifié reconduit

la date de saisie est contenue dans la dimension temps

la dimension temps est contenue dans la dimension espace-temps

la dimension espace temps est contenue dans la dimension situation

la dimension situation fait partie des 7 dimensions:

sujet, verbe, complément, situation, entrée/sortie, objectif, versionning

Remarques

On a 60 tables pour faire 60 load séparément à différents moments

On a 60 fichiers pour les gérer individuellement indépendamment les uns des autres

On les cumule pour les regarder de façon générale selon d'autres critères de sélection d'après le contenu

La segmentation donne la souplesse

On stocke selon un découpage

On lit selon n découpages

la granularité grande donne la puissance

La lecture peut être hiérarchique et multidimensionnelle

V principes d'utilisation

L'exploitation du dataware house se fait avec les principes du 'SWEET SPOT' , de la 'PAM'

et du dwh expansé

expansé veut dire 10 % rempli et 90% non rempli pour avoir l'extensibilité (scalability) en même temps que

la rapidité de déploiement et le faible coût de mise en oeuvre (grand DWH coûteux et cohérent contre petit datamart non extensible). Ici on a à la fois l'extensibilité cohérent du DWH (les places sont prévues la structure est prête) et le caractère bon marché du datamart immédiatement opérationnel (le chargement n'est pas obligatoire pour certaines tables de dimensions (axes) ou colonnes de dimensions (clés de jointures vers les axes).

SWEET SPOT = endroit qui fait partir le plus loin quand on impacte dessus

le principe du sweet spot représente la quantité optimale d'information

s'il y en a moins on peut difficilement tirer des décisions judicieuses

s'il y en a plus, cela coûte trop cher à gérer et cela embrouille

Le bénéfice de la quantité d'information disponible dans le modèle (pourcentage du total dans le monde réel)

augmente de façon logarithmique ainsi que le bénéfice de toutes choses

(supplément d'argent, supplément de nourriture)

Dans un système d'information le coût de la quantité supplémentaire d'information

augmente de façon exponentielle quand on veut s'approcher du monde réel

ainsi que dans d'autres systèmes de modélisation

Il arrive donc un moment où le coût de l'information supplémentaire à modéliser dans le système

excède le bénéfice à en tirer c'est superflu et ça coûte énormément.

A ce point précis il faut arrêter d'ajouter de l'information et commencer l'analyse pour prendre des

décisions. Si la quantité d'information excède le niveau nécessaire il faut jeter en dehors de la zone visible

pour accélérer la compréhension et l'analyse pour la décision. Il faut tailler le bloc d'information pour qu'il

corresponde aux besoins de chaque question.

Il y a en général environ sept dimensions et dans chaque dimension il y a trois ou quatre niveaux

donc il y a en tout de 24 à 36 sweet spot intéressants selon les questions. Au delà de ce nombre, ce sont des

questions spécifiques aux domaines des métiers ce ne sont plus des questions générales à toutes les entreprises.

et le système devient complexe. Le Sweet Spot c'est le bloc d'information qui se trouve à la bonne taille

et au bon endroit pour répondre à la question importante. Moralité comme il y a plusieurs questions possibles,

il faut préparer plusieurs sweet spot au préalable c'est à dire précalculer plusieurs sous-totaux dans chaque

dimension (axe) et il faut construire au départ plusieurs axes (environ 7). Puisque le manager réfléchit de façon

multidimensionnelle pour analyser et décider et puisqu'il passe d'un niveau de consolidation à l'autre au cours

de son analyse, en d'autres termes il navigue dans tous les sens, zoom in, vue détaillée, zoom out, vue panoramique

passage d'un axe à l'autre (pivoter), alors il faut que le système d'information lui permette de faire tout celà de façon

quasi instantanée (passer d'un axe à l'autre, pivoter, passer d'un niveau à l'autre, drill down) Donc il faut que le système d'information soit à l'image des trajets possibles de la réflexion du décideur.

Bref il faut que la base de données soit multidimensionnelle. Comme il coûte trop cher et il est inutile de faire tout multidimensionnel, on va rendre multidimensionnelle seulement la partie la plus aggrégée

et on va laisser dans l BDR la partie la plus fine donc la plus volumineuse.

PAM = ne considérer que les informations les plus pertinentes et les plus précieuses = diamant

ne pas inclure les informations moins vitales dans la base de données multidimensionnelle

mettre un peu plus loin les informations de deuxième importance = or

mettre encore un peu plus loin les informations de troisième importance = argent

mettre très loin les informations rarement utilisées ou de basse valeur stratégique = cailloux

rejeter hors de la BDMD et vers une BDR classique les informations de détail au niveau le plus fin

tel est le principe de classification et segmentation d'un datawarehouse en vue du data mining

Diamant = niveau zéro du flocon

Or = niveau 1 du flocon

argent = niveau 2 du flocon

Classification = par types et catégories (ex: PROJETRIM1, PROJETRIM2, PROJMOIS)

Segmentation = découpage à différents niveaux d'une échelle (ex: PROJETRIM1 96, PROJETRIM1 97, PROJETRIM1 98)

Objectif de la classification et de la segmentation: élever la granularité

Elever la granularité = accéder des milliers de fois plus rapidement aux informations au niveau supérieur choisi sans être obligé à tous les coup d'aggréger "on the fly" à partir des niveaux les plus fins.

exemples de segmentation: par dates, par lignes de produits, géographique, par unités organisationnels

Datamining = trouver le plus rapidement et le plus précisément possible les données les plus précieuse et pertinentes ( parmi des données moins précieuse

qui font gagner le plus d'argent et de compétitivité à travers une meilleure réactivité dans un environnement

compétitif à grande vitesse de changements, fluctuations et évolutions.

trouver de l'information automatiquement à partir d'une masse de données. détermination de tendances, découverte de règles,

donner à l'utilisateur la réponse qu'il ne sait pas qu'il veut en répondant à la question qu'il ne sait pas poser.

Diamant = l'information sous sa forme la plus concentrée, la plus précieuse et stratégique, le coeur de l'étoile

Etoile : système de stockage d'une BDMD avec:

* au milieu: des colonnes floconisées (contenant des codes et identifiants)

* et autour: des tables contenant les mêmes codes et identifiants d'une part et le détail

des lignes d'autre part (exemple: code client code produit code action commerciale au centre et coordonnées

client, description produits, libellés actions commerciales autour)

On rejette toutes les informations les moins vitales vers la périphérie

Branche d'une étoile: représente une dimension. Peut avoir plusieurs niveaux.ou un seul.

Peut contenir différents niveaux de consolidations et de totalisations dans une dimension

Dimensions: plusieurs dimensions peuvent se combiner en une grande dimension comme

espace + temps = situation

une dimension est représentée par un axe de l'hypercube

dans les requêtes on peut passer d'une dimension à une autre (pivoting),

choisir une dimension (slice)

sélectionner sur plusieurs dimensions (dice),

descendre d'un niveau (drill down),

déduire une dimension à partir du résultat de l'autre (drill accross),

descendre au niveau le plus bas (drill down to detail) vers la bdr à partir de l'hypercube réel.

aller de l'image multidimensionnelle virtuelle vers la bdr (drill through)

sortir de la base pour aller sur le WEB ou l'IHM (WORD EXCEL VISIO etc...) (= drill out)

exemple de dimensions: 1 sujet, 2 situation, 3 verbe, 4 compléments, 5 E/S, 6 objectif, 7 version

Hypercube: un cube comprenant plusieurs axes par exemple 7 axes principaux et 36 mini axes

exemple d'axes: 1 sujet, 2 situation, 3 verbe, 4 compléments, 5 E/S, 6 objectif, 7 version

exemple d'axes: 1 date, 2 géographie par continents pays villes, 3 gamme de produits, produits

4 organisation, unités de production, 5 axe financier

6 axe commercial marketing vente, clients,

7 axe gestion de ressources humaines

Axe: axe d'analyse pour analyser une dimension, un axe est représenté en ligne ou en colonne d'un

tableau, et dans un axe, les niveaux sont les sous totaux, par exemple si l'axe est en ligne les

niveaux sont les lignes de sous totaux, si l'axe est en colonnes, les niveaux sont les colonnes

de sous-totaux

Changer de dimension: on change de dimension en changeant d'axe d'analyse par exemple on met la ligne

en colonne ou vice versa , ou bien on met une dimension en majeur et une autre dimension en mineur

ou vice versa ou bien on enlève une dimension de la vision et on la remplace par une autre.

En somme on analyse les dimensions en manipulant les axes, on change de dimension en changant d'axes

d'analyse.

Dimensions traditionnelles:

* WHO,WHEN,WHAT,HOW, RESULTS, MEASURES

* QUI, QUOI, QUAND, COMMENT, RESULTATS, INDICATEURS

* parfois certains indicateurs sont dans l'intersection des axes et dimensions

* dimensions: FINANCES, RECHERCHES ET DEVELOPPEMENT,

PRODUCTION,MARKETING, VENTE, CLIENTELE, DRH, DOSI,DG

VI description du systeme

Dans la BDMD PROJX

L'analyse est multidimensionnelle :

1 sujet,

2 verbe,

3 complément,

4 situation (espace , temps),

5 entrée/sortie,

6 objectif,

7 versionning état de livraison.

Le stockage est en étoile

chaque branche est une dimension

chaque dimension a des niveaux

La navigation

se fait avec les possibilités de zooming dans les niveaux et de passage de dimension à dimension

elle permet le SLICE and DICE, DRILL DOWN, DRILL ThROUGH, DRILL ACROSS, DRILL OUT, DRILL DOWN TO DETAIL,

Il y a un diamant au centre de la BDMD

Le diamant c'est le centre de l'étoile

Le diamant c'est le centre du flocon

L'étoile a des branches ou axes ou dimensions

Un axe a des noeuds, une dimension a des niveaux, un noeud est un sweet spot

Autour du diamant dans le plan vertical il y a une étoile

du genre WHO,WHEN, WHAT, HOW, RESULT, MEASURES etc...

l'étoile sert à faire du PULL

PULL veut dire: lorsque l'utilisateur veut une information de n'importe quel type il peut faire une requête

comme il a besoin en mettant des conditions multicritères sur le contenu des éléments à sortir ensuite il peut

lancer sa requête générale sur l'ensemble de la BDMD du datawarehouse et il obtient la réponse précise

à sa question personnalisée rédigée par lui même à la demande au moment de la consultation de la

base.

exemple: quelles sont les queries de projetrim1

quelles sont les queries du 1er trimestre 1997

quelles sont les queries de projetrim1 du 1er trimestre 1997 à livrer

quelles sont les queries qui lisent la bdr et sont impactées par un modification de la bdr

quelles sont les queries qui consolident le niveau groupe en accédant à la BFM

cela sert pour le debugging ou l'évolution ou la gestion de composants

Autour du diamant, dans le plan horizontal il y a un flocon

le flocon sert à faire du PUSH

PUSH veut dire: le concepteur de la base prévoit à l'avance les questions fréquemment posées et les questions

importantes possibles il prépare tous les cas utiles et il construit la structure de la base sous forme arborescente

pas la technique de la classification et/ou la segmentation de telle manière que lorsque l'utilisateur arrive

il a un assortiment tout fait de menus qui lui est proposé, il n'a plus qu'à choisir la branche qu'il veut explorer

et les réponses préfabriquées lui sont présentées de façon automatique et très rapide et précis comme par magie

alors qu'en vérité on lui a déjà préfabriqué un certain nombre de chemins de requêtes qui représentent des cas connus de grande valeur et de grande fréquence d'utilisation.

L'idée est que presque tout le monde pose presque tout le temps les mêmes questions. C'est pourquoi on va préparer

à priori les mêmes réponses on va les présenter de façon immédiatement visible d'un seul coup d'oeil dans un BTI

et ensuite l'utilisateur n'aura plus qu'à aller piocher dans ce même BTI la réponse archi connue à sa question

archi usuelle.

BTI: technique qui permet de représenter une hiérarchie dans un contenant tabulaire (ex: table DB2)

Technique qui permet de se servir des fonctionnalités et qualités d'un SGBDR afin de mettre en oeuvre

les fonctionnalités et qualités des systèmes à base d'arbres, d'arbres de décisions, de graphes hiérarchiques:

SGBDOO, SG de bases de connaissances, PG systèmes experts, SGB données complexes multimédias,

Datawarehouse, Data mining, Text mining, Software component mining,

IA, Hyper textes, Hypergraphes, réseaux baysiens, hyper images, n-arbres,

hyper cubes, hyper mondes, hyper mondes virtuels, n-arbres fractals virtuels

SG bibliothèques de composants logiciels réutilisables, référentiels en arborescences, GED

groupware, intranet, HTML, Java BEANS, JDBC

exemple: à partir d'un BTI modélisé sous logiciel graphique FLOW,

saisi sous EXCEL avec RIRnD,

stocké sous DB2 avec tables liées,

on peut afficher la hiérachie dans une page HTML

où le clic de la souris dans une cellule de la BTI de la part de l'utilisateur

déclenche un JAVA BEANS

qui appelle un JDBC

qui s'interface à un ODBC

qui lit une base relationnelle en langage SQL

et rend la réponse de la BDMD du dataware house (ou du FLOCON PUSH)

qui s'affiche dans la page HTML

en face du BTI qui demeure visible

en même temps que la réponse à la requête PUSH HYPER QUERY

HYPER QUERY: on donne une sorte de menu avec des cases sous forme BTI ou table finale de folio

l'utilisateur clique dans une cellule de la BTI et obtient immédiatement la réponse parcequ'une requête

sous jacente a été lancée parce que la cellule est active et le clic dans la cellule lance une query

QUERY parce qu'une query a été lancée, HYPER parce que ça a été fait par un clic de souris comme

lorsqu'on clique sur un mot et cela donne un texte c'est un hyper texte.

Hyper query virtuelle: au lieu de déclencher la requête au clic, le système donne le nom de la requête qu'on peut lancer immédiatement en cliquant sur 'changer d'écran' et 'lancer la requête sous DB2' ou ACCESS.

le flocon part d'un n-arbre fractal virtuel

On dit flocon parceque ce n'est pas une ligne directe comme une dimension à niveaux (année trim mois)

il y a n arbres qui aboutissent à des feuilles qui contiennent des listes dont chaque élément pointe vers

un élément du centre de la BDMD (son diamant) donc il y a des éventails et des rateaux ce qui fait des flocons (ensemble d'éventails arborescents autour d'un centre) et pas des étoiles (ensembles de directions autour d'un centre)

le NFV appartient à une BC (base de connaissances multimédia) gérée par un SGBCE

(e =ensembliste = qui permet de sortir des ensembles, = qui permet de faire des requêtes générales sur tous les éléments selon leur contenus d'après des critères de sélection).

(e=par opposition aux requêtes de SGBDOO qui gèrent des objets complexes et sortent un objet à la fois sans

traiter l'ensemble des éléments en général et sans sortir des collections comme réponses et sans pratiquer extensivement les critères de sélection selon le contenu).

Les SGBDOO sortent des objets en poupées russes qui peuvent être gros mais en général ils sortent un à un

du genre voiture-moteur-filtre-boulon et ne sortent pas souvent les ensembles de 500000 comptes clients

d'une grande banque ressources fortements rémunérées du trimestre encours.

BC = traite les objets complexes et multimédias par opposition aux BDR qui ne traitent que les objets simples et les données. BC : traite souvent des données textuelles (WEB) avec en plus des images et du multimédia.

Le NFV ici est un 4-arbres pour les queries = 1 folio, 2 tâche, 3 niveau de consolidation, 4 temps

et au dessus c'est un 2-arbres = 1) découpage par analyse programmation mise en oeuvre

2) découpage par :"donnez moi tout ce qui concerne tel sujet".

selon le principe du OEPA (One Entry Pulls All)

utilisé à la fois dans C.A.Jasmine et Softlab Enabler.

On trouve donc deux n-arbres imbriqués

base de connaissances projx

dataware house projx

bdmd projx. hypercube

table de dimension

dimension = sujet

sujet = query (en d'autres circonstances le sujet peut être un select

ou bien on peut rajouter la procédure clistau dessus de la query pour pouvoir

sélectionner toutes les queries d'une clist)

folio 1 car

projetrim1

premier 3 car

ancien 3 car

nouveau 3 car

projetrim2

premier 3 car

ancien 3 car

nouveau 3 car

projmois

premier 3 car

ancien 3 car

nouveau 3 car

date saisie

trim 1 car

mois 2 car

annee 4 car

libellé 60 car

base de connaissances projx

dataware house projx

bdmd projx. hypercube

table de dimension

dimension = situation

position: espace: composants et deploiement implementation

query

ex rl111prt

application:

ex: projetrim1

job

ex: rprtqm01

procédure

ex: rp103prt

clist:

ex: rc200prt

folio

ex folio 1

date position

ex 1 5 1997 = 1er trim 5 ème mois 1997

statut

ex 111 existant modifié reconduit

date statut

ex jj mm aaa

VII Exploitation

Tâches à faire à la fin de PROJETRIM1 et pour bien commencer PROJETRIM2

* Imprimer toutes les queries nouvelles de PROJETRIM1

- Dernière version livrée

- Segmentées par packages

- Classifiées dans l'ordre de la CLIST

gestion des composants pour projetrim2

* lister les queries nouvelles de projetrim1

* créer une bibliothèque de queries nouvelles de projetrim1 après généralisation

il faut que cette bibliothèque soit exhaustive: point de départ indispensable pour le travail dans projetrim2.

* remplir la bibliothèque de généralisation à l'aide de deux bibliothèques

- la bibliothèque derniers livrés

- la bibliothèque de départ de livraison

* une fois la bibliothèque de généralisation remplie elle donne la liste de toutes les queries livrées en

premier trimestre 1997 pour projetrim1. Cette liste doit être exhaustive sinon on oublie des développements

pour PROJETRIM2.

cela ne suffit pas car il y a des queries déjà livrées et déjà overrided

il faut identifier les queries nouvelles qui tournent actuellement en cti

parmi les queries déjà livrées

pour cela il faut comparer la liste de queries livrées avec la procédure CLIST qui tourne

* Ayant obtenu enfin la liste de toutes les queries livrées et qui tournent réellement

on doit segmenter cette liste selon les packages. Un package est une division logique qui

s'inspire de la division des tâches vers les ressources. Un package à ce niveau c'est un folio

ou un équivalent-folio.

Pour exécuter la segmentation de la grande liste exhaustive: s'inspirer de la procédure CLIST qui
sépare bien les folios

Il faut faire autant de petites listes que de packages administratifs afin de pouvoir aborder chaque chose

séparément avec chaque développeur séparément et terminer, valider chaque partie au fur et à mesure qu'on

avance dans le travail. Sinon rien n'est validé, tout est en cours et c'et difficile de suivre.

* En même temps que la tâche de segmentation il est nécessaire de faire la classification dans l'ordre

de la procédure CLIST sinon c'est très lent de trouver la présence ou l'absence d'une query qui doit être
quelque part

La classification dans l'ordre de la procédure CLISTpermet l'accès direct en s'aidant de la procédure
CLIST ou en connaissant la CLIST. L'absence d'ordre oblige ) pratique la recherche par balayage séquentiel à
chaque fois qu'on a besoin de consulter une liste au lieu de pouvoir faire l'accès direct de façon ergonomique.
La classification dans l'ordre permet de faire beaucoup plus rapidement les comparaisons nécessaires et
inévitables entre les diverses listes dont on dispose par exemple comparaison entre la listes de queries livrées
par les développeurs à la recette et la liste des queries qu'ils doivent livrer.

* Après avoir obtenu une série de listes de queries nouvelles livrées qui tournent

listes segmentées et classifiées on met dans la dimension sujet

La dimension sujet est constituée d'un table de dimension sujet qui contient toute la dimension sujet

et de n tables réparties en 3 séries qui contiennent:

série 1 anciennes = A

série 2 nouvelles = P pour prochain

série 3 qui tournent en CTI = E pour exploit.

chaque série contient une segmentation en packages = folios ou équivalent-folios

chaque package a une classification dans l'ordre de la CLIST

* Pour l'instant on ne met dans la dimension sujet que les queries nouvelles.

Pour l'instant, très temporairement, on ne remplit que

la grande table de dimension sujet du datawarehouse

* Ensuite on pratique la segmentation de la grande table de dimension sujet du datawarehouse

en reportant les segments vers

les 10 datamarts petites tables de dimension sujet nouvelles queries

* On reporte pour plus tard le renseignement

des datamarts petites tables de dimension sujet anciennes queries

et des datamarts petites tables de dimension sujet queries en exploitation

question: quelle est la différence entre prochain et nouveau?

réponse: un prochain peut être un existant modifié et reconduit

alors qu'un nouveau peut être un non existant précédemment, créé de toutes pièces et mise en exploit.

Passage de PROJETRIM1 à PROJETRIM2

On veut être capable de dire quelles queries de PROJETRIM2 doivent être touchées et livrées en s'inspirant de PROJETRIM1

A partir de la PROCÉDURE CLISTPROJETRIM1

1°) Principe d'exclusion

1.1 Exclusion de ce qui ne tourne pas

1.2 Exclusion de ce qui n'est pas touché cette fois ci

Pour avoir ce qui tourne et qui doit être touché

c'est à dire les nouveaux prochains

2°) Principe d'exhaustivité

Tout ce qui tourne et qui est nouveau

et parmi les nouveaux que ce qui tourne.

il ne faut pas en oublier

Il ne faut pas en avoir trop (exemple des livrés mais qui ne tournent plus)

Il faut le nombre exact.

3°) Principe de segmentation

Segmenter en 10 packages

BDR f1 f2 f3 f4 f5 f6 fb majbdr majsuivi

Parceque chaque package est déjà gros (exemple folio 1)

4°) Principe de classification

Classer dans l'ordre de la CLIST

éventuellement donner un numéro d'ordre

exemple prendre le numéro à gauche de l'écran

ou bien faire 3 colonnes de 2 caractères chaque: premier ancien nouveau

5°) Principe d'automatisme

5.1 Rendre automatiques les comparaisons en mettant les membres de bibliothèques

dans des fichiers puis dans des tables et ensuite manipuler ces tables par du SQL

pour faire les comparaisons, les jointures, les exclusions, les sélections et les classifications dans l'ordre

en somme pratiquer les recherches multicritères et appliquer les fonctions de l'algèbre relationnel sur des

éléments qui étaient à l'origine des membres de bibliothèques TSO et des parties de procédures CLIST

En somme gérer des composants en masse par les techniques de gestion de bases de données relationnelles

et utiliser les résultats de ces requêtes relationnelles pour alimenter des bases de données relationnelles

organisées en dataware house avec stockage en étoile et flocons, structures en hypercubes pour disposer de

bases de données multidimensionnelles afin de faire des queries de datamining sur ces BDMD contenant des

descriptions de composants logiciel en fait faire du Software componant mining à partir d'alimentations

automatisées par queries.

5.2 Rendre automatique la transformation de procédure CLIST en résumé de procédure
CLISTcontenant que les queries.

en faisant passer la PROCÉDURE CLIST à travers un programme LG3 (COBOL,VB,JAVA etc...)

6°) Glissement tectonique des 3 colonnes premier ancien nouveau

ça glisse tout en restant. Ca reste tout en glissant. Ca augmente tout en gardant la même taille

carroussel sur 3 plots, rotation volley pour les noms.

=========================================================================

Etapes pour le repérage des queries à toucher

Etape I

Changer procédure CLISTen résumé sous forme fichier SAM

LOAD dans table DB2 avec ordre de la CLIST

Transformation de procédure CLISTen résumé par L3G

Etape II

Changer bib membres en fichier SAM

LOAD dans table de queries livrées

Etape III

Comparer résumé procédure CLISTet résumé bib de livraison

en utilisant L4G SQL

Comment faire le raffinage?

* on peut partir des datamarts contenant des queries nouvelles non ordonnés et les ordonner une à une à partir

de la procédure clistdécoupée en packages

* On peut aussi faire une chaîne de raffinage qui exécute un processus de raffinage comme le raffinage du pétrole, la fabrication de ciment, le montange de voitures, la normalisation d'adresses en milieu urbain, le générateur automatique d'organigrammes, les chaînes de montages de téléviseurs, l'affitout.

Méthode de raffinage

1°) Prendre les procédure CLIST exhaustives ordonnées, les concaténer, les raffiner, en faire un résumé

2°) Prendre les bibliothèques de départ de livraison et derniers livrés. Les concaténer. Cela donne toutes

les queries livrées

3°) Faire

SELECT A.nom_de_query

FROM nom_clist A, liste_queries_livrées B

WHERE a.nom_de_query = B.nom_de_query

ORDER BY numéro_d_ordre

cela donne en résultat : toutes les queries nouvelles prochaines livrées à toucher

4°) Segmenter en 10 packages

bdr f1 f2 f3 f4 f5 f6 fb majbdr majp60

5°) Mettre en 10 packages dans la table de dimension SUJET du datawarehouse

6°) Segmenter la table de dimension SUJET du datawarehouse

en 10 datamarts tables de dimension SUJET

SELECT *

FROM table_SUJET

WHERE package = folio1

relancer 10 fois

7°) En face des queries PROJETRIM1 ajouter les queries PROJETRIM2

8°) Donner un numéro d'ordre sur 3 colonnes de 2 car chaque

1 - premier

2 - ancien

3 - prochain

Grande table de dimension objectif

La grande table objectif a un infinité de lignes de 79 caractères de texte plus le nom de query et nom de select et la date de saisie etc...

Pourquoi infini?

parce que le problème se pose ainsi:

il y a 50 pour cent de commentaires à 1 ligne,

30 pour cent de commentaires à 2 lignes

15 pour cent de commentaires à 3 lignes

5 pour cent de commentaires à 4 lignes ou plus

pour quoi 1 ligne? parce qu'on veut le plus court possible

pour quoi 4 lignes ? parce qu'on veut 100 pour cent exhaustif

et exhaustif veut dire tout lister et parfois il y en a beaucoup et/ou décrire en entier la formule de calcul et prfois elle est longue

pourquoi exhaustif ? car sinon on ne comprend pas la formule et on est obligé de passer plus de temps à étudier la query en devinant l'intention de la personne qui a écrit au départ.

donc le problème se résume ainsi: on veut consommer le minimum de place lorsqu'il y a besoin d'une ligne pour ne pas perdre la place et le temps de se déplacer et la peine de sortir un large enregistrement mais on veut également pouvoir tout mettre en cas de besoin de 4 lignes de commentaires.

la réponse technique à cette question (être économe et rapide en cas de besoin d'une ligne et être exhaustif et clair en cas de besoin de 4 lignes) c'est de faire des lignes numérotées de 1 à 4 jusqu'à l'infini (l'infini comparé au besoin de 4 est ici 99 ou bien 36 à la puissance 2) et ne fabriquer des lignes numérotées qu'au fur et à mesure des besoins.

c'est à dire qu'on ne fabrique pas 1 ligne de 60 à priori elle serait trop petite dans 50 pour cent des cas et on ne fabrique pas une ligne de 60 * 4 non plus car elle serait trop grand de 3 / 4 vide dans 95 pour cent des cas mais elle serait encore trop petite dans certains cas rares qui on besoin de 6 lignes

ainsi comme on donne 36 à la puissance deux de possibilité on est à l'abri des besoins en nombre de lignes possibles et on est aussi à l'abri des gaspillages et ralentissements dans le cas où les lignes prévues sont trop grandes. Ici d'après cette solution technique, les lignes suivent les besoins elles seront 1, 2, 3, 4 ou plus selon le besoin de chaque query tout en sachant que 50 pour cent des queries ont 1 ligne description de ce qu'elles font, 30 pour cent ont 2 lignes, 15 pour cent ont 3 lignes et seulement 4 pour cent ont 4 lignes ou plus.

Cette solution résoud tous les cas de figures même les plus extrêmes de 1 à 36*36 lignes.

C'est pour cela que c'est infini comparé à 4 lignes pour 99 pour cent des cas

Pourquoi ne pas mettre toute la query?

parceque la query est déjà dans prochain (trim,mois,rir3da)

pourquoi ne pas laisser les commentaires à consulter dans la query?

Première raison

parceque lorsqu'on pose la question quelle query traite quel sujet quelle rubrique, pertes sur créances, la bibliothèque de référence prochain ne répond pas à cette question elle contient toutes les querie mais ne donne pas instanténément la query qu'on cherche il aurait fallu afficher une à une les queries pour lire leur contenu en balayage fastidieux et lent avant de trouver la bonne query ou bien il faudrait avoir l'organigramme sous les yeux et parcourir l'organigramme visuellement en scannant jusqu'à trouver la bonne query sauf que dans l'organigramme il n'y as qu'un tout petit embryon de commentaire sujet verbe complément qui n'est pas aussi compréhensible que la description de query sur n fois 60 caractères ou n fois 72 caractères

Deuxième raison

pourquoi on doit séparer les commentaires des queries pour les voir seuls:

c'est parceque c'est plus rapide de parcourir 50 commentaires affichés côte à côte à la queue leu leu dans le même fichier que de parcourir 50 membres tso.

Troisième raison

Il est également plus rapide de parcourir que les commentaires plutôt que chercher dans une meule de foin d'une grosse QUERY les aiguilles commentaires des SELECT qu'on veut identifier étudier pour modifier ou débugger. En effet il arrive très souvent d'avoir à parcourir une grosse QUERY (objet polymorphe) pour rechercher LE SELECT qu'on veut et dans ce cas les lignes non commentaires gênent et noient. On veut trouver ce qu'on cherche d'abord (ex: dotations) avant de plonger dans le SELECT lui même pour faire de la programmation. Avant de plonger verticalement dans les profondeurs d'un SELECT il est plus rapide de parcourir horizontalement superficiellement les titres de QUERIES un peu plus évocateurs que les seuls noms ou sujet-verbe-complément de l'organigramme. C'est le principe de l'onglet: avant d'entrer dans le texte qui noie, on parcours d'abord les onglets, avant d'entrer dans les paragraphes qui noient on parcours d'abord les sections, avant d'entrer dans les sections qui noient on parcours d'abord les chapitres, avant d'entrer dans les chapitres qui noient on parcours d'abord les titres de livres et la table des matières. c'est le principe de segmentation, classification des dataware house qui permet d'accélérer la recherche parmi des données au préalable épurées et classifiées et ordonnées et segmentées pour au préalable réduire d'abord le champ d'investigation avant d'investiger plus profondément . C'est comme le principe du push data qui consiste à ne donner que les données préalablement choisies et ne pas donner les données qui ne sont pas pertinentes. En somme cela évite de se noyer dans les queries non cible quand on est à la recherche d'une query cible. Pour éviter de se noyer dans les queries non cibles on met une étiquette à chaque query et on ne regarde que l'étiquette comme on regarderait l'étiquette d'un tiroir sans avoir à l'ouvrir. Si on ouvre bestialement tous les tiroirs en se précipitant et en s'énervant c'st possible aussi de trouver la portion de query qu'on recherche parmi les centaines de queries mais c'est moins rapide que chercher dans une table de commentaires où on n'aurait que les commentaires descriptifs et les noms de queries sans être gêné par les corps des queries et seulement lorsqu'on a trouvé l'étiquette de query qu'on veut on peut ouvrir le tiroir et voir toute la query à 100 pour cent. cela évite de la perte de temps en enlevant les obstacles sur la voie de circulation de la recherche.

Quatrième raison:

lorsqu'on est en développement, les queries ne sont pas terminées elles se trouvent dans l'environnement de développement et non pas dans prochain environnement de stockage de produits finis mais néanmoins il y a la nécessité et l'urgence de déjà répertorier et manipuler les queries du point de vue externe (ce qu'elles doivent faire) et non pas du point de vue interne (comment elles le font, est ce que c'est juste, qu'est ce qu'elles font exactement). Si l'externe est juste (l'intention, l'objectif, le but) l'interne peut être faux (la réalisation, le codage, les tests) mais même si l'interne est faux (on doit le changer) cela ne doit pas empêcher qu'on puisse avoir la libre possibilité de manipuler les queries de façon externe (leur nom, leur position dans la procédure, dans la CLIST, leur position dans l'organigramme, leur gestion en temps que composant, leur appartenance à telle ou telle application ou package, telle version de logiciel à mettre en oeuvre.)

en d'autres termes on doit pouvoir manipuler, gérer, répertorier, recenser, placer dans la CLIST, identifier, des queries même si elles sont encore en développement et pas encore finalisées. c'est à dire que les virgules peuvent change mais l'intention de départ et le nom reste pareil on doit pouvoir les manipuler avant la fin de la fin du dernier des derniers tests de recette . Par exemple on doit pouvoir identifier la query dans l'organigramme avant que la query soit écrite et on doit pouvoir décrire les spécifications de la query avant qu'elle soit réalisée et livrée. Et dans tout cette phase développement on doit pouvoir manipuler la définition de la query (sa description) plutôt que la query elle même avec tout son listing. C'est comme on doit pouvoir avoir bien clairement définis les descriptifs et spécifications d'un pont, d'un avion, d'un bâtiment, d'un progiciel, d'un programme cobol avant que ces choses sont construites et terminées. Il n'est pas pratique de vouloir obliger de se référer au listing d'une query pour toute étude de la query car le listing est trop verbeux et trop dépendant d'une syntaxe d'un langage informatique et à certaines étapes de réflexions on n'a pas besoin d'aller au niveau de la programmation on a au contraire besoin de faire abstraction du niveau de la programmation et on a besoin de rester au niveau de l'analyse et au niveau du français en faisant abstraction de l'implantation informatique en langage pour la machine. Si on est obligé de lire le code informatique, cela ralentit. Si on est obliger de sauter le code informatique pour retrouver les phrases en français dans le listing, cela ralentit aussi. La seule solution la plus rapide pour lire ce qu'on veut lire (le français) c'est de ne se faire afficher que le français sans le langage informatique qui gêne la lecture rapide et ralentit la recherche et la réflexion.

Cinquième raison:

dans la quatrième raison on a besoin de manipuler l'intention de la query avant que la query soit livrée à la recette (pendant que la query est en développement). La cinquième raison c'est qu'on a besoin de manipuler la query sous sa forme en français et de description au moment de sa conception au moment où elle n'existe pas encore où elle passe de l'état de non existance à l'état d'existance. Dans ce cas précis il n'y a pas de raison de dire de regarder le listing de la query puisque la query n'existait pas donc son listing n'existe pas encore. Il est également hors de question de dire de regarder le résumé de la query dans l'organigramme (sujet-verbe-complément) car étant donné que la query n'existe pas, alors son organigramme n'existe pas non plus. Donc au moment de sa naissance, de son passage du néant à l'existance il faut bien lui donner 1°) son nom 2°) sa description en langage humain et 3°) éventuellement une série de ses caractéristiques comme par exemple sa date de naissance, son lieu de naissance. Et se travail là, au lieu de se dérouler sur un bout de papier au crayon ou sur un bout de texte sous word, peut très bien se dérouler directement dans une table bien structurée sous DB2 ou ACCESS ou EXCEL ou un tableau WORD ou n'importe quel logiciel une peu structuré sous forme tableau qui puisse contenir des colonnes, des lignes, des cellules, des données du texte. (même si c'est du FLOW avec un tableau) ainsi la réflexion n'est pas perdue, elle est structurée et réutilisable jusqu'à la fin de la vie qe la QUERY. (on lui donne son nom une fois dans sa vie on la baptise une fois et on la décrit une fois dans sa vie sauf si elle évolue, mais pour la plupart des queris on les décrit une fois)

exemple: le travail de conception des queries doit se faire comme ceci:

nom, description

nom, description

nom, description

et ce travail de conception ne doit pas se faire en dehors du data ware house car sinon il y aurait besoin d'une resaisie dans le data ware house de la description des queries

étant donné que les queries sont décrites au moment où les queries sont crées, alors le chemin le plus court entre la conception des queries et le référencement répertoriation des queries est le chemin dont la longueur est égale à zéro: si on conçoit en saisissant dans le dataware house au fur et à mesure qu'on conçoit alors la conception est automatiquement répertoriée, référencée dans le data ware house consultable par tous pour faire de la programmation réalisation et du développement. Ensuite une fois que c'est développé, programmé réalisé, testé, validé, recetté, livré, expérimenté, généralisé, alors le reste de la query c'est à dire son corps, son listing, la suite de ses caractéristiques seront référenciés et répertoriés dans le dataware house aussi. Mais au début, à la naissance de la query à sa conception, étant donné que ce n'est qu'une ligne (éventuellement complétable et extensible, amendable, avenable, évolutive, modifiable) il n'y a aucune raison de ne pas la référencer immédiatement dans le data ware house puisque sa structure (de conception) est exactement pareil à sa structure définitive (en exploitation).

ainsi lorsque plus tard on cherche une query concernant un sujet pour réutiliser ou faire évoluer, on aura une bibliothèque de queries bien documentée à accès rapide comme un système expert de gestion de bibliothèque de queries composants logiciels réutilisables.

Illustration

On doit pouvoir se mettre comme devant un mur entier avec plusieurs armoires et lire les étiquettes des armoires et ouvrir la bonne armoire sans être obligé d'ouvrir toutes les armoires en séquence dans le cas où il n'y a pas d'étiquette, on doit pouvoir jeter un rapide coup d'oeil sur plusieurs mètres carrés de tiroir et capturer instentanément avec les yeux les étiquettes des tiroir, repérer en une fraction de seconde le bon tiroir et n'ouvrir que ce tiroir et pas les autres (au cas où il n'y aurait pas d'étiquettes on serait obligé d'ouvrir tous les tiroirs en s'arrachant les cheveux) et ensuite, on devrait pouvoir parcourir rapidement d'un seul doigt les onglets des dossiers pour sortir élégemment avec seulement deux doigts le précieux dossier recherché au lieu d'être obligé de parcourir en séquence toutes les armoires du bureau, ouvrir tous les tiroirs des armoires, sortir tous les dossier des tiroir ceci est le scénario catastrophe de quelqu'un qui aura refusé de mettre des étiquettes sur ses armoires, et dans ses armoires sur ses tiroire et dans ses tiroirs sur ses dossiers, quelqu'un qui aurait refusé de faire le rangement, la classification, la segmentation, l'oraganisation, l'ordonnencement de ses dossiers.

Dans le système d'information de PROJETRIM c'est pareil: il faut ranger, classifier, segmenter, organiser, ordonner, il faut étiqueter et décrire essentiellement en un ligne chaque query, mettre cette description quelque part de facile d'accès et rapide d'accès pour pouvoir trouver les queries de la façon la plus rapide possible et la plus précise possible. le graphique est bien pais le graphique est limité dans le nombre de mots à allouer à chaque query (seulement trois mots) et le graphique n'est pas toujours existant et à jour. A certaines étapes le graphique n'existe pas encore et donc le graphique est nécessaire pour une recherche rapide et visuelle mais une fois le graphique vu et bien lu il doit être complété par un niveau d'abstraction plus bas que le graphique mais quand même plus haut que le listing de la query . Car il existe aujoud'hui un trou (fossé, gap, vide) entre le niveau d'abstraction du graphique (organigramme) (qui ne traite que les queries et pas les SELECT qui n'a que trois mots et pas trois lignes) et le niveau de la query où on est gêné par le listing verbeux quand on recherche une description succinte précise mais sur des centaines de queries. A priori on ne sait pas laquelle qu'on veut chercher on ne connait pas son nom, on ne sait pas ou elle se trouve tout ce qu'on sait c'est qu'on recherche une query qui fait telle ou telle fonction, et la fonction est décrite plus clairement dans la description de query que dans l'organigramme où les dessinteurs on tendance à supprimer des informations vitales pour la recherche (s'il manque trois caractères vitaux dans l'organigramme (comme 104 = pertes) alors on ne trouve pas la query qu'on cherche en regardant l'organigramme, dans ce cas il ne reste plus qu'aller perdre son temps à plonger de façon fastidieuse dans toutes les queries au hasard avant de trouver la bonne.

ce qu'il faut éviter c'est être obligés de faire constamment p7 et p8 pour avancer et reculer dans les queries alors qu'on veut à tout prix éviter le corps des queries indésirables qui encombrent et on ne veut que les entêtes des queries pour trouver la query cible. En somme la démarche c'est, dans un texte encombré d'informations encombrantes effacer toutes les informations inutiles et encombrantes pour ne laisser que les informations précieuses qu'on veut trouver à un moment donné. il ne faut pas avoir à dérouler le texte en entier car la fenêtre est toute petite et on est aveugle quand on est sur un SELECT on ne voit pas les autres SELECT à moins de fait p7 p7 ou p8 p8 p8 et lorsqu'on se trouve sur le nouveau on ne voit plus l'ancien. Le problème c'est aussi qu'on doit voyager de query en query en sortant d'un membre d'une query et en entrant dans un autre membre ce qui est lent fastidieux et fait beaucoup de manipulation alors qu'il serait beaucoup plus simple, beaucoup plus rapide de rester dans un même membre avec toutes les descriptions de queries collées les unes aux autres faciles à englober d'un seul coup d'oeil facile à dérouler rapidement, facile à scanner facile à lire, facile à parcourir vers l'avant et/ou vers l'arrière pour faire des recherches, c'est un membre beaucoup plus petit que le listing entier et il y beaucoup moins de bruit. cela s'appelle le nettoyage.

Résumé:

Il faut faire le rangement, la classification (par types), la segmentation (par niveaux), l'ordonnancement (mettre dans l'ordre: ex: l'ordre de la CLIST), et aussi faire le nettoyage (comme enlever les inutilités) faire le raffinement (comme raffinage du pétrole brut pour faire le kérosène) le filtrage (comme le tamisage pour enlever la boue pour retenir l'or)

en clair il faut faire le DELETE, le ERASE de tout ce qui n'est pas nécessaire pour ce type de recherche qui revient très souvent. Il faut faire le SELECT faire une sélection au préalable de ce qu'on sait pertinemment qui est utile précieux et nécessaire et qui revient souvent (la même question revient tout le temps: quelle est la query qui fait telle chose? traite telle donnée? ou se trouve-t-elle? quel est son nom?). Il faut isoler la description de queries qui est précieuse et la séparer du reste des queries dont on n' a que faire parce que ce ne sont pas des queries qu'on cherche et qu'on veut voir.

Lorsqu'on cherche une query, il ne faut pas que cette recherche soit gênée par le contenu des autres queries qu'on ne cherche pas.

il faut séparer l'entête des queries du corps des queries pour qu'on puisse ne parcourir que l'entête des queries afin de trouver plus rapidement la query qu'on cherche et seulement alors on peut aller à un endroit de référence lire le listing d'une seule query la query cible et ne pas être obligé de lire comme parcourir dans la jungle de sables mouvants et gluants, de racines et de branches toutes les queries inutiles avant de tomber enfin à bout de souffle et de journée dans la query qu'on cherche c'est du gaspillage d'énergie bêtement.

Description de la table de dimension objectifs

71 caractères pour reprendre l'existant sous DB2